Tag Info

Hot answers tagged

102

The simple stuff PATH=$PATH:~/opt/bin PATH=~/opt/bin:$PATH depending on whether you want to add ~/opt/bin at the end (to be searched after all other directories, in case there is a program by the same name in multiple directories) or at the beginning (to be searched before all other directories). You can add multiple entries at the same time. ...


30

You can use tr. $ tr ':' '\n' <<< "$PATH" /Users/arturo/.rvm/gems/ruby-1.9.3-p392/bin /Users/arturo/.rvm/gems/ruby-1.9.3-p392@global/bin /Users/arturo/.rvm/rubies/ruby-1.9.3-p392/bin ... You can also do this in some shells (tested in bash and zsh): echo -e ${PATH//:/\\n} In zsh, you can use the $path variable to see your path with spaces ...


24

Either way works, but they don't do the same thing: the elements of PATHare checked left to right. In your first example, executables in ~/opt/bin will have precedence over those installed, for example, in /usr/bin, which may or may not be what you want. In particular, from a safety point of view, it is dangerous to add paths to the front, because if ...


22

Add cd /home/xxxx/Documents/Scripts/ if you want your job to run in that directory. There's no reason why cron would change to that particular directory. Cron runs your commands in your home directory. As for ssmtp, it might not be in your default PATH. Cron's default path is implementation-dependent, so check your man page, but in all likelihood ssmtp is ...


21

Note the output here: root:/usr/local/bin# siege bash: /usr/bin/siege: No such file or directory Bash maintains an internal hash of previously found executables in your path. In this case, it has details that at one time there was an executable at /usr/bin/siege, and reuses that path to avoid having to search again. You need to tell bash to manually ...


20

Probably to keep the kernel simpler. I don't think the kernel ever searches your path to find an executable. That's handled by the C library. #! processing is done in the kernel, which doesn't use the standard C library. Also, I don't think the kernel has a notion of what your path is. $PATH is an environment variable, and only processes have an ...


19

Having more entries in $PATH doesn't directly slow your startup, but it does slow each time you first run a particular command in a shell session (not every time you run the command, because bash maintains a cache). The slowdown is rarely perceptible unless you have a particularly slow filesystem (e.g. NFS, Samba or other network filesystem, or on Cygwin). ...


19

You cannot solve this through shebang directly, since shebang is purely static. What you could do is having some »least common multiplier« (from a shell perspective) in the shebang and re-execute your script with the right shell, if this LCM isn't zsh. In other words: Have your script executed by a shell found on all systems, test for a zsh-only feature ...


16

Grepping around in /etc turned up a link that Googling did not. It turns out you can control this in the file /etc/fstab. Just add a line that says none / cygdrive binary 0 0 and the problem should be fixed. No more kludgey fixes in .bashrc, and no messed-up $PATH.


16

Suppose that the new path that we want to add is: new=/opt/bin Then, using any POSIX shell, we can test to see if new is already in the path and add it if it isn't: case ":${PATH:=$new}:" in *:$new:*) ;; *) PATH="$new:$PATH" ;; esac Note the use of colons. Without the colons, we might think that, say, new=/bin was already in the path because ...


15

Not an interesting solution at all, but very portable: PATH=${PATH}:/my/path/1 PATH=${PATH}:/my/path/2 PATH=${PATH}:/my/path/3


14

On some systems, which -a shows all matches. If your shell is bash or zsh¹, you can use type instead: type foo shows the first match and type -a foo shows all matches. The three commands type, which and whence do mostly the same thing; they differ between shells and operating systems in availability, options, and what exactly they report. type is always ...


14

All the commands that a user might want to run are in the PATH. That's what it's for. This includes commands that you run directly, commands that other people run directly, and commands that you or other people run indirectly because they are invoked by other commands. This is not limited to commands run from a terminal: commands run from a GUI are also ...


14

The risk is someone put a malicious executable in the directory that happen to be your current one. The worst case happen when: you are logged as root as the malicious command has unlimited damage power . is at the beginning of your PATH as standard commands can be overridden without you noticing it (typically an ls which could hide itself from the list). ...


13

I've seen people clean up duplicates from their PATH variable using awk and something like this: PATH=$(echo "$PATH" | awk -v RS=':' -v ORS=":" '!a[$1]++') You could try adding that to your own bashrc and make sure you source the other files somewhere before running that. And alternative would be to use this pathmearge utility. As for your speed ...


13

What you are looking for is the PATH environmental variable. It tells the shell, where it needs to look for programs. You can see the current value of that variable using echo: echo "$PATH" Now... The best practice if you want use some new program is to install it using the package management program for your distribution. But in this case, I assume you ...


13

In zsh $PATH is tied (see typeset -T) to the $path array. You can force that array to have unique values with: typeset -U path And then, add the path with: path+=(~/foo) Without having to worry if it was there already. To add it at the front, do: path=(~/foo "$path[@]") if ~/foo was already in $path that will move it to the front.


12

For bash use type -a assemble.sh


12

If you're the only user on the machine it's OK, as long as you know what's you're doing. The general concern is that by having your current directory in PATH, you cannot see commands as a constant list. If you need to run script/program from your current directory, you can always explicitly run it by prepending ./ to its name (you saying the system "I want ...


12

That's not the Bourne shell, or bash emulating the Bourne shell, that's the Almquist shell, in your case probably the Debian Almquist shell (a Linux fork by Debian of BSDs' sh itself based on the original Almquist shell). In the Almquist shell (the original one and the modern versions), % is used in PATH for extra features specific to ash. Quoting from the ...


11

You simply can't do this. There's no way¹ the make process can change its parent's environment (or its current directory, which you might be thinking of next). In fact, even less is happending than you think. Not all make implementations reflect the assignment to the make PATH variable in the environment; GNU make (found on Linux and other systems) does, ...


11

I do not know if it works in zsh, but it works in bash: PATH=$(paste -d ":" -s << EOF $PATH /my/path/1 /my/path/2 /my/path/3 EOF ) Edit and even shorter: PATH=`paste -d ":" -s << EOF $PATH /my/path/1 /my/path/2 /my/path/3 EOF` And without spawning a process: new_path=( "$PATH" /my/path/1 /my/path/2 /my/path/3) OLD_IFS="$IFS" export ...


11

Use the command shell builtin: bash-4.2$ function date() { echo 'at the end of days...'; } bash-4.2$ date at the end of days... bash-4.2$ command date Mon Jan 21 16:24:33 EET 2013 bash-4.2$ help command command: command [-pVv] command [arg ...] Execute a simple command or display information about commands. Runs COMMAND with ARGS suppressing ...


11

Global paths should be set in /etc/profile or /etc/environment, just add this line to /etc/profile: PATH=$PATH:/path/to/ANT/bin


11

On linking You generally do not link /usr/local/* with /bin, but this is more of a historical practice, in general, there are a few "technical" reason why you cannot do what you're suggesting. Making links to executables in /bin can cause problems: Probably the biggest caveat would be if you're system is having packages managed by some sort of package ...


10

That line in your .profile should be one of export PATH="$PATH:$HOME/Unix/homebrew/bin" PATH="$PATH:$HOME/Unix/homebrew/bin" PATH=$PATH:$HOME/Unix/homebrew/bin PATH=$PATH:~/Unix/homebrew/bin The ~ character is only expanded to your home directory when it's the first character of a word and it's unquoted. In what you wrote, the ~ is between double quotes ...


10

If you don't already have duplicates in the PATH and you only want to add directories if they are not already there, you can do it easily with the shell alone. for x in /path/to/add …; do case ":$PATH:" in *":$x:"*) :;; # already there *) PATH="$x:$PATH";; esac done And here's a shell snippet that removes duplicates from $PATH. It goes through ...


9

Zsh has an sh compatibility mode which will let it execute POSIX sh code and some bash extensions. As long as you don't use bash features that zsh doesn't have (with the same syntax), you can have the same file sourced by both shells. Use the emulate built-in to put zsh in compatibility mode; with the -L option, the emulation is local to the enclosing ...


9

I'd create a file /etc/commonprofile and source it in both /etc/profile and /etc/zsh/zprofile. This gives you the opportunity to share common settings and still use bash respectively zsh specific settings and syntax in /etc/profile respectively zprofile.


9

Yes and no. In a POSIX environment, the utilities must behave as described by the specification. In practice, this means that conforming versions of the utilities must be present in $PATH. However, when running your program on a POSIX-compliant system, you may be running it in a non-conforming environment. In practice, what often happens is that the OS has a ...



Only top voted, non community-wiki answers of a minimum length are eligible