I'm having trouble executing a fish shell script I created. I added it to a custom path I added using fish_add_path. The folder appears just fine in $fish_user_paths and $PATH, and i've CHMOD +x the file, but when I type the name of the file, (which is pickc ath the moment), it can't find the command. How do I add fish scripts to the path and execute them like any other cli command (e.g. pickc)?
The content of the script is:
#!usr/bin/fish
colorpicker --short --one-shot --preview | sed -z 's/\n//g' | xclip -selection c
pkill picom
picom -b
I can execute the script just fine with the fish -c pickc command, but I can't execute with ./pickc, which gives me the error
Failed to execute process './pickc'. Reason: The file './pickc' does not exist or could not be executed.
I have doubly confirmed that the path in the $PATH and $fish_user_variable variable does lead to the folder containing the script.
Edit: I noticed that my paths were all really messed up somehow. The below answer does fix the issue of not being able to execute it, so thanks
You have mistyped your shebang. Switch
#!usr/bin/fish
to
#!/usr/bin/fish
or whatever path which fish shows.
Related
I'm installing a command line program called plink that recommends this:
The PLINK executable file should be placed in either the current
working directory or somewhere in the command path. This means that
typing "plink" or "./plink" at the command line prompt will run PLINK,
no matter which current directory you happen to be in. PLINK is a
command line program -- clicking on an icon with the mouse will get
you nowhere.
I have the PLINK executable file. What should I do next?
Run 'chmod +x plink' to grant the file execution rights.
I tried to implement a bash command system("cd /home/user") in perl , but I get an error saying
Can't exec "cd": No such file or directory at temp.pl
Is there a way to change the current working directory to the specified one , and the change remains after the perl script has exited also.
No. A process can't change its parent process's current working directory. Shells implement commands like cd as "builtins", meaning they're a function in the shell itself, and not a separate process that gets run.
You can change the current directory in perl using chdir($dir), and that change will be inherited by child processes — but it won't be passed along to the parent process.
When you want to change the directory inside your Script, you can use the Perl command chdir('dir')
Example:
chdir($dir);
You actually cant modify the directory of the parents process, but you can of the current process
You cannot modify the current working directory of a different process in UNIX, at least not without some serious hackery.
This is why cd is a built-in in all shells. It is not an external program (nor can it be implemented as an external program).
cd is not a process, it is a shell builtin command that changes the current working directory for that shell process.
So use system("sh -c 'cd /my/dir'"). but here system command itself invoke another shall so still it not change directory.
use chdir for that.
cd is not a process, it is a shell builtin command that changes the current working directory for that shell process. So system("sh -c 'cd /cat/bat'") would "succeed", but still wouldn't change the working directory of your perl process; use chdir for that.
I am having trouble launching an executable that I have created from a shell script. I would like to automate testing by running the program many times with different command line options to verify it is working.
When I type echo $SHELL, /bin/sh is displayed.
The following is my shell script:
#!/bin/sh
clear
echo "Running first test."
./myProgram
exit 0
When I run the script (sh myScript.sh), with myProgram in the same directory, I see the following output:
Running first test.
: not foundsh: line 4:
When executing the program ./myProgram, it runs as expected with no command line options.
I have also tried:
myProgram
./myProgram &
myProgram &
based on answers to somewhat similar questions, but they all result in the above error message.
Your newlines are goofed. Use dos2unix to fix.
why don't you try using the full path?
e.g., if myProgram is in /home/user1/bin, you can try /home/user1/bin/myProgram instead of ./myProgram. This should work.
You can also add the path to path variable, $PATH and directly call myProgram from anywhere.
Run "export PATH=$PATH:/home/user1/bin" on your terminal without the quotes. Note that this affects only your current termial session. If you want to permanently add the path, update your .bashrc file in your home directory with the following line:
I have a perl script exist in the follwoing path (/home/Leen/Desktop/Tools/bin/tool.pl)
Every time I want to run this tool I go to the terminal
>
and then change the directory to
..../bin>
Then I run the perl by writing
..../bin> perl tool.pl file= whatever config= whatever
The problem is that I want to run this perl script without the need to go to the bin folder where it exist . so I can run perl script from any directory and as soon as I enter shell
I went to the etc/environment and I wrote the follwoing
export PERL5LIB=$PERL5LIB:/home/Leen/Desktop/Tools/bin
But when I go to terminal and write the follwoing straight ahead without going to bin folder where tool.pl exist
>perl tool.pl file=... config=...
it says the file "tool.pl" does not exist???
The first argument to the perl program is the path to an executable file. These calls are equivalent:
:~$ perl /home/Leen/Desktop/Tools/bin/tool.pl
:~$ perl ~/Desktop/Tools/bin/tool.pl
:~$ perl ./Desktop/Tools/bin/tool.pl
:~/Desktop/Tools/bin$ perl tool.pl
:~/Desktop/Tools/bin$ perl ./tool.pl
etc.
In the shell the tilde ~ expands to your home directory, and ./ symbolizes the current directory. On *nix shells (including the various terminal emulators on ubuntu), the command prompt ususally is $ in nomal mode, # as root user and seldom %. > Is a secondary command prompt, e.g. when continuing a multiline argument, unlike cmd.exe on Windows.
The PERL5LIB variable determines where Perl looks for modules, not for executable files.
You can set a script as executable via chmod +x FILENAME. You can then call the script without specifying the perl program:
:~/Desktop/Tools/bin$ ./tool.pl
You can modify the PATH variable to change where the shell looks for executables. The PATH usually contains /usr/bin/ and other directories. You can add a directory of your own via
PATH=$PATH:/home/Leen/Desktop/Tools/bin
Add your directory at the end of the PATHes, so you don't overrule other programs.
If you want to set this permanently, you can add this line to the file ~/.bashrc (only for your user and only for the bash shell).
Then you can call your script from anywhere, without a full path name:
:~/foo/bar$ tool.pl
You should consider using a more specific command name in this case, to prevent name clashes.
I found this piece of code in perl
system("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude");
However I don't understand how it is working. I mean system() is used to fire 'system' commands right ? So is this 'zip' command used here a 'system' command ?
But I tried firing just the following on the command prompt;
zip $ZIP_DEBUG -r -9 itvlib.zip arg1 arg2
It didn't work !
it gave the following error:
'zip' is not recognized as an internal or external command,
operable program or batch file.
Well this shouldn't have happened, since the command seems to use 'zip' as a system command. So this makes the command 'zip' mysterious
Can you please help me to understand this command with all its parameters?
It's probably not working since you're not replacing things like $ZIP_DEBUG with their equivalent real values. Within Perl, they will be replaced with the values of the variables before being passed to the system call.
If you print out those Perl variables (or even the entire command) before you execute that system call, you'll find out those real values that you need to use. You can use the following transcript to guide you:
$ perl -e '
> $ZIP_DEBUG = "xyzzy";
> $include = "inc_files";
> $exclude = "exc_files";
> print "zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude";
> '
zip xyzzy -r -9 itvlib.zip inc_files exc_files
For details on how system works, see here. For details on what zip needs to function, you should just be able to run:
man zip
from a command line shell (assuming you're on Linux or its brethren). If, instead, you're on a different operating system (like Windows), you'll have to figure out how to get the zip options out. This may well be as simple as zip -? of zip -h but there's no guarantee that will work.
If it's the same as the Info-ZIP zip under Linux (and it may be if you have the -9 and -r options and your exclude variable starts with -x), then zip -h will get you basic help and zip -h2 will give you a lot more.
system("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude");
is running a program named zip (probably zip.exe) somewhere on the path. $ZIP_DEBUG, $include, and $exclude are Perl variables that are interpolated into the command line before the command is run.
If the system call works in the Perl script, but zip -? gives the 'zip' is not recognized as an internal or external command, operable program or batch file error, then the PATH of the Perl script must be different than the PATH in your command prompt. Or, there might be a zip command in the current directory when Perl executes the system command. (In Windows, the current directory is an implicit member of your PATH.)
To see what the PATH is for the Perl script, you can add a print "$ENV{PATH}\n"; before the system command. To see what the PATH is in your command prompt, type PATH.
Yes, zip is a system command. The variables $ZIP_DEBUG and such are perl variables that are interpolated to the command before launching zip.
To debug what the actual call is, try adding:
print("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude\n");
See perldoc for details on system.