Is it secure to have ~/bin/ it the PATH?
It's a default behaviour of at least bash. It's as secure as your home directory is.
Start all of your commands with a comma (2009)
31–40 of 130 posts
Re: Start all of your commands with a comma (2009)
#32In the comments, the author argues against the underscore by saying Bash/Zsh already uses it for completion. But it looks like it's a Zsh thing - at least my Bash install is pretty conservative about it.
Not sure what I have installed/sourced, but "_" says there are 381 possibilities for me. (This is with bash.)
Also in the article itself, the author argues against any prefix char that requires using the shift key.
Re: Start all of your commands with a comma (2009)
#33I do something a bit special... Instead of naming my script foobarnator (and hence risking that another foobarnator may exist in the future and may clash with my script), I name my script foobarnatorToBeAliased.sh. Then in my list of aliases I alias foobarnator to foobarnatorToBeAliased.sh.
The alias itself looks a bit weird in that to pass arguments to an aliased command you need to use a function (in Bash at least AFACIT) but it all works fine.
As aliases aren't sourced when other scripts are running, I'm sure my scripts/commands ain't ever going to clash with anything.
I've been doing that since years.
It also works fine to add "wrappers" to existing commands: for example to add additional input sanitization catching common mistakes I'm making when calling some commands.
Re: Start all of your commands with a comma (2009)
#34Clever trick. Too bad there's no good way to namespace commands. It would be interesting if you could have, for instance: $ mkdir -p /tmp/bin/my $ printf '%s\n%s\n' '#!/bin/sh' 'echo hello' > /tmp/bin/my/hello $ chmod 755 /tmp/bin/my/hello $ PATH="/tmp/bin:$PATH" $ my/hello hello
> mkdir -p /tmp/bin/my
This is not a secure way of using /tmp.
Re: Start all of your commands with a comma (2009)
#35Is it secure to have ~/bin/ it the PATH?
If someone can write to your home directory they can also update your bashrc file and add whatever they want to PATH
Re: Start all of your commands with a comma (2009)
#36Earlier quoted context omitted.
It can if you are executing programs that then try to execute those commands and get your commands instead.
I wish it was easier to create "snapshots" of a particular set of environment variables in order to use them later as run environments. I also wish that Unix desktop environments generally made it easier to manage env vars, but that's another complaint. And don't get me started on PAM env vars...
Just env vars?
env > "$(date +s).env-snapshot"
Re: Start all of your commands with a comma (2009)
#37Cool.
I’m gonna start them with `å` just to be a little different.
Re: Start all of your commands with a comma (2009)
#38I tend to give programs longer, more descriptive names and then do the short names as shell aliases. That way there’s little risk of name collision for the original program, scripts using the canonical name remain readable, and the shorthand is free to evolve to fit varying work habits.
My keyboard came with a tab key, so I don't worry about my commands having short names.
Until you have five commands which all use the prefix `sort-incoming-` and then three commands named `sort-incoming-hourly` and `sort-incoming-monthly` etc.
Re: Start all of your commands with a comma (2009)
#39Clever trick. Too bad there's no good way to namespace commands. It would be interesting if you could have, for instance: $ mkdir -p /tmp/bin/my $ printf '%s\n%s\n' '#!/bin/sh' 'echo hello' > /tmp/bin/my/hello $ chmod 755 /tmp/bin/my/hello $ PATH="/tmp/bin:$PATH" $ my/hello hello
Plan 9 does that, I'm not sure why it never made it into Unix because I always loved it. Your networking-related commands were in `/bin/ip` and you'd run e.g. `ip/ping 1.1.1.1`. If you created the dir `$home/bin/rc/my` and put scripts in it, they would have been runnable as `my/hello` etc like in your example.
Re: Start all of your commands with a comma (2009)
#40I do something a bit special... Instead of naming my script foobarnator (and hence risking that another foobarnator may exist in the future and may clash with my script), I name my script foobarnatorToBeAliased.sh . Then in my list of aliases I alias foobarnator to foobarnatorToBeAliased.sh . The alias itself looks a bit weird in that to pass arguments to an aliased command you need to use a function (in Bash at leas…
What has always been a blocker for me to follow your example, is the desire to use many such scripts from the command lines provided inside an $editor or $email client. There probably is a way to configure both of them to see the aliases, but it's more straightforward to just have everything in the PATH.