Start all of your commands with a comma (2009)(rhodesmill.org) |
Start all of your commands with a comma (2009)(rhodesmill.org) |
Then again, I don't really believe in performing complex operations manually and directly from a shell, so I don't really understand the use-case for having many small utilities in PATH to begin with.
The real issue isn't collisions though, it's discoverability. Six months later you forget half of what you wrote. The prefix at least lets you type gps-<tab> and see everything at a glance.
On my most frequently used machine/dev env this means -
e for vim
m for mise
n for pnpm
c for Claude
x for codex
j for just
I use fish abbreviations for this, as they expand to the full command in the shell history.
Or prefix files in the local bin dir with a couple letters from your username, like /home/ahepp/.local/bin/ah-mycommand
It went weird pretty quickly...
dude, whois my.carquick, easy and consistent. entirely voluntary.
Bravo
$HOME/bin/cmd
c=$HOME/bin/ ; ${c}cmd # if you really are dead set on obfuscating your scripts.
Rather than the limited "magic of tab completion" I prefer the simple, yet general ls $HOME/bin
Also seems convenient to be able to type ,<tab> to autocomplete over your custom commands, in case you forgot the name you assigned them.
Off-topic: What the hell is that font on this website? And why does the "a" look like that?
But I'm now facing the problem that LLM agents don't like this, and when I instruct them to run certain tools, they remove the leading comma. It's normally fixed with one extra sentence in the prompt, but still inconvenient.
It is objectively cleaner to keep your user scripts in your home, that way they are only in _your_ PATH, whereas putting them in /usr/[local/]bin implicitly adds them to every [service] user on the machine, which I can see creating obscure undesired effets.
Not even mentioning the potential issues with packages that could override your scripts at install, unexpected shadowing of service binaries, setuid security implications, etc.
2024: https://news.ycombinator.com/item?id=40769362
#!/usr/bin/env -S cargo eval --
// cargo-deps: derive-error="0", is_executable="0"
// vi: ft=rust
use derive_error::Error;
use is_executable::IsExecutable;
use std::collections::{BTreeMap, HashSet, btree_map};
use std::os::unix::fs::MetadataExt;
use std::path::{Path, PathBuf};
#[derive(Debug, Error)]
pub enum Error {
VarEnv(std::env::VarError),
Io(std::io::Error),
}
fn main() -> Result<(), Error> {
let mut paths_seen = HashSet::new();
let mut path_fileid_seen = HashSet::new();
let mut exes_seen = BTreeMap::new();
for path in std::env::var("PATH")?.split(":") {
let path = PathBuf::from(path);
if !path.is_dir() {
continue;
}
if !path_fileid_seen.insert(path.metadata()?.ino()) {
continue;
}
if paths_seen.insert(path.clone()) {
match std::fs::read_dir(&path) {
Err(_) => {
eprintln!("error listing {:?}", path);
}
Ok(readdir) => {
for entry in readdir {
let entry = entry?;
if entry.path().is_executable() {
let mut item = match exes_seen.entry(
String::from(entry.path().file_name()
.unwrap().to_string_lossy().as_ref()))
{
btree_map::Entry::Vacant(v) => v.insert(vec![]),
btree_map::Entry::Occupied(o) => o.into_mut(),
};
item.push(path.clone());
}
}
}
}
}
}
for (exe, paths) in exes_seen.into_iter() {
if paths.len() == 2 {
let mut strs = vec![];
for path in paths.iter() {
strs.push(path.to_str().unwrap());
}
if strs.as_slice() == ["/usr/bin", "/usr/sbin"] {
continue;
}
}
if paths.len() > 1 {
println!("{}: ", exe);
for path in paths {
println!(" {}", path.to_str().unwrap());
}
println!("");
}
}
Ok(())
}However, I'd advocate for an ë key then.
`.local/bin` seems to be much more common in my experience for this use case. And for good reason.
they're both so easy to reach for
If I introduce an alias (like `grep='grep --binary-files=without-match --ignore-case --color=auto`) that matches the name of a system binary - I probably do that intentionally.
And if I EVER need to call grep without my alias - I just prefix it with a backslash: \grep will search with case sensitivity and no color and will scan binaries.
Yes, I can do path ordering to override usual commands. However, having a set of odd-job scripts which start with a comma gives a nice namespacing capability alongside a well narrowed-down tab-completion experience.
While it's not the neatest thing around, it works surprisingly well.
Another idea which looks useless until you start using is text expanders (i.e.: Espanso and TextExpander).
I've never had this collision problem yet, despite appending my script directory to the end, but I'll use either of the above solutions if that ever becomes a problem.
You use shadowing to fix issues where you install some software that expects you to have a sane and ~recent version of some tool like git, but you don't as your system provides that binary and unfortunately it is either not sane (not GENERALLY sane [while it could be sane for system scripts]) or not recent enough. In that case the program's function would simply fail if it would call the system's binary and you shadow the binary with your version to fix that.
> adding your script directory in front of the PATH
That's a poor advice for the scripts you call relatively frequently. Instead, (as a general approach, we aren't discussing some particular script) don't use shadowing for scripts: just pick a non-conflicting script name and append the script's dir to $PATH.
alias curl='/opt/homebrew/opt/curl/bin/curl '
alias rsync-copy='/opt/homebrew/bin/rsync -avz --progress -h '
alias rsync-move='/opt/homebrew/bin/rsync -avz --progress -h --remove-source-files '
alias rsync-synchronize='/opt/homebrew/bin/rsync -avzu --delete --progress -h '
alias rsync-update='/opt/homebrew/bin/rsync -avzu --progress -h '
alias vi='/opt/homebrew/bin/vim -S ~/.vimrc'
alias vim='/opt/homebrew/bin/vim -S ~/.vimrc'
alias wget='/opt/homebrew/bin/wget -c '
Thanks, mathfailure - this genuinely improves my life!
> I just prefix it with a backslash: \grep
Word of warning, I use `\grep` quite frequently. The usage is when you are piping after grep or saving to a variable.
Illustrative example:
$ TO_DL=$(curl "https://foo.com/releases/" \
| grep -e "latest" \
| head -n1 \
)
$ curl $TO_DL
curl: (3) bad range in URL position XX
https://foo.com/releases/latest.tar.gz
^^^^^^
Annoying footgun, but something to be aware of in case you go down this extremely confusing rabbit hole like me. I couldn't figure it out until I decided to hexdump the string.
[Side note]: My first thought reading the article was also about how `\` basically solves the problem but they do have one advantage in that they can do `,<tab>` and get a list of all their custom commands. Personally not worth it for me but I can definitely see this being useful for some. Especially on shared systems. But getting everyone to prefix a script name seems just as unlikely as getting everyone to place programs in the right location.
Call it the Chesterton’s Fence of ‘which’.
And then there’s Claude. It deletes whatever it finds at ~/.local/bin/claude, so I have to use a shell function instead to invoke the full path to my wrapper.
alias claude="sandbox-exec -f ~/agents-jail.sb ~/.local/bin/claude --dangerously-skip-permissions"Because I cannot imagine much 3rd party scripts working with random flags added to core tools
Random flags added to core tools are done with aliases, which do not affect the launched processes, not by shadowing them in ~/bin. Shadowing in ~/bin are for cases where a newer (compared to the system-wide version) or custom version of a tool is needed.
On MacOS I shadow that way just curl and git binaries to the versions installed from homebrew and nothing has broken (yet). I know that tar on MacOS is also a weirdo that I'd rather shadow with the homebrew's gtar, but their args are different and I of course understand that there's a high probability of something in system to be bound to mac's version of tar, so here I better remember to use 'sane' tar as gtar or use an alias (instead of shadowing the binary) for tar to use gtar (because aliases are for users, not for system scripts/processes).
And on my home desktop's Debian - I don't even use shadowing of binaries at all (never needed it).
Also, I just realized: I change PATH env via my shell's rc script (~/.zshrc), so I probably could worry even less about shadowing system binaries (like tar on MacOS) possibly breaking things.
Btw on the second suggestion, I think there's a command named `command` that can help with that sort of thing, avoids recursive pitfalls.
Don't tell people to sacrifice agency for apocalypse insurance that doesn't work, lol
In such cases you might get errors like sl being both a version control system and the steam locomotive
Easy autocomplete, I know there won't be any collision, and which command is mine.
You put keyseqs in ~/.inputc, set a keyseq-timeout, and it just works.
openssl ,v openssl --versionThen again most of the examples OP gave are usually available as short options, and aliasing ,s to sudo is certainly possible. So the only one which makes sense to me is ,,=$. But it's probably not worth the trouble to my muscle memory.
Every tool and shell that lay in arm's reach treated the comma as a perfectly normal and unobjectionable character in a filename.
Neat trick! I don’t think I’ll namespace everything this way, because there’s some aliases and commands I run so often that the comma would get annoying, but for other less frequently used helper scripts then this will be perfect!
This convention was suggested by the GNU Arch version control system years ago (maybe 20??), but it's really useful for the same tab completion reason and I have kept it for almost two decades, even when I switched to git.
File names or directories starting with a comma where considered “junk”, and ones with a plus sign I think where considered “precious”.
The problem in other distros is that if you prefix PATH so that it contains your executable "foo", and then run a program that invokes "foo" from PATH and expects it to do something else, the program breaks.
With Nix, this problem does not exist because all installed programs invoke all other programs not via PATH but via full absolute paths starting with /nix/store/HASH...
* https://news.ycombinator.com/item?id=40769362 (2024, 169 comments)
* https://news.ycombinator.com/item?id=31846902 (2022, 123 comments)
* https://news.ycombinator.com/item?id=22778988 (2020, 90 comments)
I started using a prefix because I like very short script names that are easy to type
I prefer giving scripts numbers instead of names
Something like "[number"
I use prefixes and suffixes to group related scripts together, e.g., scripts that run other scripts
I have an executable directory like ~/bin but it's not called bin. It contains 100s of short scripts
I create a home directory "x" for executables that I want to manage as files, and don't want on PATH or as alias.
To run foo: ~/x/foo
For example I have GNU date as ~/x/date so it's independent of the system BSD date.
I'd prefer to use underscore (when writing BASH scripts, I name all my local variables starting with underscore), but a simple two or three letter prefix would also work. I don't like the idea of a punctuation prefix as punctuation usually has a specific meaning somewhere and including it as the first character in a filename looks wrong. (e.g. Comma is typically used as a list separator and it's a bit of cognitive dissonance to see it not used in that context)
Nowadays, I tend to skip using a personal prefix and just try to name commands with a suitable verb in front (e.g. "backupMySQL") and ensure that there's no name collisions.
I would replace underscore with “-“ or “.”
> I don't like the idea of a punctuation prefix as punctuation usually has a specific meaning somewhere and including it as the first character in a filename looks wrong.
So you don’t use dotfiles? ;)
I'm not convinced by "quicker to type" arguments as that's rarely the bottleneck, so I'm perfectly happy with using underscores in filenames and variables. I wouldn't use underscore as the beginning character of a filename unless it had a specific meaning to me (e.g. temporary files), so I'd be more inclined to use a two or three character prefix instead.
I also discovered the comma thing myself, and use it for `xdg-open <web-search-url>` aliases, i.e. `,aw xdg` searches archwiki for "xdg", since the SteamOS on this thing doesn't have manpages.
alias words='iftty xargs' # join by spaces
alias c='compgen -c | sort -u | words' # eg: c | grep ^k | chop
# ... a for aliases, f for functions etc ...
alias man='g !archman' # https://man.archlinux.org
alias ,aw='g !aw' # https://wiki.archlinux.org
alias ,mdn='g !mdn' # https://developer.mozilla.org
alias ,nix='g !nixpkgs' # https://search.nixos.org
# ... a dozen others ...
g() { local IFS=+; xdg-open "https://ddg.gg/?q=$*"; }
iftty() { if [ -t 1 ]; then "$@"; else cat; fi; }
chop() { # [TABS] [STARTCOL] [CUTOPTS..] # eg. ls ~/.co* | chop
set -- "${1:-2}" "${2:-1}" "${@:3}"
cut -c "$2"-$(($2+8*$1-2)) "${@:3}" | column #| less
}
clashes() { # [CMDS..] # print overloads eg: clashes $(c)
(($#)) || set -- $(compgen -A alias -A function)
local ty cmd; for cmd; do ty=($(type -at "$cmd"))
((${#ty[@]}>1)) && echo -n "$cmd "; done; echo
}If we want to stay within (lowercase) alphabetic Latin characters I think prefixing with the least common letters or bigrams that start a word (x, q, y, z, j) is best.
`y' for instance only autocompletes to `yes' and `ypdomainname' on my path.
Choosing a unique bigram is actually quite easy and a fun exercise.
And we can always use uppercase Latin letters since commands very rarely use never mind start with those.
Also, kudos to keeping it so concise and to the point, thats some prime writing.
I thought the title meant I should type ,ls instead of ls.
Like so?
I have a command named "decolour", which strips (most) ANSI escape codes. Clear as day what it does, almost nobody uses this spelling when naming commands that later land as part of a distribution.
I do something similar with my personal scripts — prefix them with a short namespace. The real win isn't just avoiding collisions though, it's tab completion. Type the prefix and tab, and you immediately see all your custom stuff without wading through hundreds of system commands.
The 2009 date on this is wild. Some of these simple unix conventions age better than most frameworks.
If I ever wanted to achieve what you initially wanted to achieve - I could use something like
alias -s sh=sh
alias -s bash=bash
alias -s zsh=zsh
Just like I do bind .txt and .conf to 'less', .pdf to 'qpdf', .json to 'ijq', video formats to 'mpv' and so on.
Sure enough, they got run. The scripts didn’t take over your account. They ran “ls” and “more”. They may have also logged your username in a file so he could lord it over you.
This can also happen by downloading something off the internet (git clone, or tar xz foo.tar.gz), or on a multi-user system (eg. someone can put any of these common commands into /tmp/ and wait for you to drop into it and try a "ls" there) — if you have any untrusted content anywhere, you are exposed.
Might even be as simple as “detect if I’m running gnu sed or bsd sed and use the appropriate one”. Obviously you can not have this problem by being smart about other things but defense in depth right?
Oh, that's without even going into the security risks and loss of portability.
I was learning Pascal on AT&T 3B2 systems. They were running SVR3. Perfectly normal clustered systems with nifty things like RFS. We were all logged in via dumb terminals, and the machines were sequestered on another floor. I had pictured them as big, really big. But 3B2s were not.
Anyway, our first lessons were how to use the Bourne shell and how to use "vi" to edit our source code.
I had learned to type 4 years previously, so I was already fast and fearsomely accurate. But I still made mistakes.
So one day I typed "ci filename.p" and then I had an hour's worth of sheer horror!
"ci" had not spawned the visual editor as I had hoped, but it did something inexplicable to that file! It had renamed it to "filename.p,v" and had put a bunch of garbage into it!
I can't remember how much "RCS garbage" was inserted, or how much cleanup I needed to do. For some reason, our TA/lab assistants were not available for me to ask! I was in a cold sweat, because all my hard classwork had been utterly mangled by this unfeeling machine, and I didn't know how to effectively undo it.
Eventually I learned about the RCS system, and what those curious "$...$" symbols meant, and I think I worked out a way to "undo" it (which I think consisted of merely "co" to checkout the file again.)
But it was a rude awakening to the fact that simple command-line typos could have some very unintended consequences!
NixOS simultaneously smooths the path to using absolute paths while putting some (admittedly minor) speed-bumps in the way when avoiding them. If you package something up that uses relative paths it will probably break for someone else relatively quickly.
What that means is that you end up with a system in which absolute paths are used almost everywhere.
This is why the killer feature of NixOS isn't that you can configure things from a central place; RedHat had a tool to do that at least 25 years ago; it's that since most of /etc/ is read-only, you must configure everything from a central place, which has two important effects:
1. The tool for configuring things in a central place can be much simplified since it doesn't have to worry about people changing things out from under it
2. Any time someone runs into something that is painful with the tool for configuring things in a central place, they have to improve the tool (or abandon NixOS).
/nix/store/grep-hash -flags files | /nix/store/head-hash
instead of: "grep -flags files | head"?
For non one-off sorts of things, you would substitute in the nix expression "${gnugrep}/bin/grep" the "${gnugrep}" will expand to "/nix/store/grep-hash" and also make a dependency on the gnugrep package, so that the grep install won't get garbage-collected as long as your package is still around.
Here's an example[1] from a package expression for e-mail client I use, which will shell out to base64 and file. Upstream relies on these two programs being in $PATH, but this replaces the string used for shelling out with the absolute path in the nix store.
For shell scripts, I'll just do something like this near the top:
GREP="${GNU_GREP:-$(command -v grep)}"
1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/no...
[user@nixos:~]$ which grep
/run/current-system/sw/bin/grep
[user@nixos:~]$ ls -l /run/current-system/sw/bin/grep
lrwxrwxrwx 1 root root 65 Jan 1 1970 /run/current-system/sw/bin/grep -> /nix/store/737jwbhw8ji13x9s88z3wpp8pxaqla92-gnugrep-3.12/bin/grep
I find brevity easier to work with. I wish all software was like that
I like the shell (ash not bash). I like assembly language
I have to "adjust" to verbosity, and sometimes I honestly can't, it's paralyzing to the brain, terseness feels more natural
Why not name scripts in natural language like an LLM prompt perhaps (I don't use LLMs so pardon the ignorance), with spaces and punctuation
Bash allows it
echo echo hello > "dear computer, please output the word \"hello\". thank you"
chmod +x "dear computer, please output the word \"hello\". thank you"
"dear computer, please output the word \"hello\". thank you"
But neither of those things is true. The scripts are for communicating with a computer and are intended to be used only by me
UNIX allows anyone to rename any file to whatever they want. The UNIX user is free to pursue their own preferences in naming, whatever those may be
A prisoner, new to a particular cell block, was surprised to discover that his fellow inmates passed much of their day by calling out numbers, after which they would laugh heartily for a few moments. Every few minutes an inmate would call out a number and everyone would laugh, and then, after a few moments of silence, someone else would call out a number, and once again laughter. The inmate asked one of the other inmates whom he'd come to know to explain this strange behavior to him.
"It's simple", came the reply. "We know all of our jokes by heart, and there's really no reason to tell them at lenght. Instead, we simply call them out by number."
Though this was strange to him, the new inmate thought he'd join in on the fun. After a few weeks listening to the jokes, he took some initiative and called out "number 27!". But nobody laughed. This seemed very strange to him, since he'd heard others call out that same number, with everyone laughing afterwards. After waiting and waiting, with still no laughter, he finally asked: "why is it that when others call out that joke you laugh, and when I called it, nobody laughed?".
The reply promptly came: "You told it wrong".
> Something like "[number"
> It contains 100s of short scripts
So you call scripts like [1 [2 [3 [4 ... and remember what each one of them does? If yes - that's nuts, I'd visit a doctor.
But I'm not you
~/.local was only invented around 2003 and gained widespread usage maybe 15 years or so ago...
People used ~/bin already in the 90s ;-)
I snapshot my entire home directory every hour (using btrfs+snapper), but I exclude ~/.local/ from the snapshots. So I use ~/.local/bin/ for third-party binaries, since there's no reason to back those up; and ~/bin/ for scripts that I wrote myself, since I definitely want to back those up.
This is a pretty idiosyncratic use though, so I'd be surprised if many other people treated both directories this way.
~/bin predates it.
And of course you can use both.
~/.local/bin is tedious to write, when I want to see directory content and - most important - I treat whole ~/.local/ as managed automatically by other services and volatile.
(Anything that modifies standard behaviour is not in PATH, but instead a shell function present only in interactive shells, so as not to break scripts.)
Unix lore: Early unix had two-letter names for most common names to make them easy to type on crappy terminals, but no one* letter command names because the easier were reserved for personal use.
I thought was for mixin externally provided systems like Homebrew, local is for machine or org-level customizations, and ~ is for user-level customizations.
It kind of goes against the idea why dotfiles are dot-prefixed.
Yes, but a lot of commands behave differently for -h and --help.
> aliasing ,s to sudo is certainly possible
Sure, but my ,s key sequence doesn’t just expand to sudo. It actually moves the cursor to the start of the current line, prefixes the command with sudo, and then moves the cursor to the end of the line. The idea is when you type a command which requires root privileges but forget to use sudo, you can just hit ctrl+p ,s to fetch the previous command and prefix it with sudo. This is what it looks like in ~/.inputrc: ",s":"^Asudo ^E"
It does seem to do some more complex stuff now that would've been annoying, but not impossible, to write as a shell script.
Still viable though for something like rg... Maybe you run it before you install it for the first time on a new machine.
The advantage of /opt is that multi-file software stays together. The disadvantage is that PATHs get long.
Also - surely vim auto-reads your vimrc?
I.e., you have "." as the very last item in your path. You are in /tmp/ (so a directory other uses can write files to). You mean to type "ls -l something" to look for "something" files. But instead, you just miss the space, and type "ls-l something*", and some other nefarious user has left a /tmp/ls-l binary behind just waiting to be run. It could package up your ~/.ssh folder and ship it off to "nefarious" user, and then do a proper "ls -l" so that you may not even notice the typo.
And, if you happen to be root when you are in /tmp and mistype ls-l, and if the ls-l binary checks to see if it is being run as root, it could then do even worse. For example, it could leave behind an suid to root bash or sh executable in 'nefarious user's' home dir, so that 'nefarious' can now become root at some point later and proceed to actually 'own' the system.
"I don't understand. I very specifically appended `.` at the end!"
Of course you can stick a comment "#the following should always be at the end of the file" or whatever or say "we should always make sure to reference binaries by their full path, so always write out `/opt/bin/busybox` rather than just `busybox`" and stuff like that. With enough system you can make this unlikely.
It does contain the issue a bit though:
I'm running isync in a systemd service, yet the program "mbsync" is not in my path. I have several services installed, yet their programs aren't in my path. My e-mail client shells out to "file" for mime-type verification, yet "file" is not in my path.
Run "compgen -c |wc -l" to get a list of commands; its over 7000 on my Ubuntu system and right around 2000 on my NixOS system.
As an aside, the packages that put the most executables in my path are probably going to be in the path for most NixOS installs (231 just for coreutils+util-linux):
27 /nix/store/csxa6mi2mpjl9vqxbv2j0bha6sz6nbjw-cups-2.4.14
31 /nix/store/334afxah19b3hr6ll93pfxlcyhhh2vws-pipewire-1.4.9
31 /nix/store/h2jsb5i4yfblr2f3ac2c7zpmlmj7zjym-perl-5.40.0
33 /nix/store/914x32c982bs3i1998yxvkg9svm3ycr5-shadow-4.18.0
33 /nix/store/a6s3hzj3b2z6rsyfkjyxwn265iyfl2gn-mtools-4.0.49
33 /nix/store/jky7jszaci5n7g426wf6nsg5dmik9nfw-kbd-2.9.0
37 /nix/store/2v1l6mqz0d7mfpp4ksw2048v3g0a1a19-hplip-3.25.2
45 /nix/store/90wlc37ljr6rpy2lan46bp0gq19vbgl5-iptables-1.8.11
48 /nix/store/1byhxs7b28grh8s15jc2dvs2zg36swjb-lvm2-2.03.35-bin
61 /nix/store/9xwxjkrwxjsvc5gs1l0syr4wbfvvvvcn-bluez-5.84
64 /nix/store/zf8qy81dsw1vqwgh9p9n2h40s1k0g2l1-systemd-258.2
72 /nix/store/1igrj9w84w7s3r80l3nkxcqwd84sw9mz-qemu-10.1.2
106 /nix/store/v4q3154vdc83fxsal9syg9yppshdljyk-coreutils-full-9.8
125 /nix/store/3c6r8gh8zrqw8xmncmlj9vivz9rz6r30-util-linux-2.41.2-binWhat can be a problem is muscle memory, when you expect it to autocomplete one way and it doesn't because something you want now shares first two or three letters with something else in your path. That's where FIGNORE comes in.
Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's ls binary is in the dir that's to the left of your '.' dir.
> The current directory ( . ) is not in PATH by default, for security reasons. This prevents accidentally running unintended programs in your current directory.
-- POSIX Shell scripting from scratch, By Sultan Zavrak (states it in general terms. They also use ls as an example though, which shouldn't be affected if you have "." at the end.)
Practical UNIX and Internet Security has an example of "." (or having a null entry in the PATH, which also indicates the current directory; I didn't know that![0]) at the beginning, which is obviously a bad idea, but he (Simson Garfinkel) makes a good point:
> More generally, you should never have a path that is writable by other users.
Ah yes, finally, he covers a situation where you have a directory at the end of your path, that is writable by others ("." would count) and having a trojan named "mroe" (for "more") waiting patiently for the superuser to mess up.
He even goes so far to say that root should run commands with full paths, such as /sbin/chown and not just chown. I've never gone that far, except I can see the benefit of doing that in scripts.
So anyway, besides the typo example, there's also a kind of shadowing: let's say you expect a command to fail because the program is not installed. Or maybe you try to run a command you think is installed but it's not. You might even have a command or way of working that tries various commands until one works. If you have a path that someone can write to (including ".") then instead of failing, it will run something unintended, if they have shadowed that command in that directory.
[0] to quote the bash man page: A zero-length (null) directory name in the value of PATH indicates the current directory. A null directory name may appear as two adjacent colons, or as an initial or trailing colon.
My goal is to prevent Claude from blowing up my computer by erasing things it shouldn't touch. So the philosophy of my sanboxing is "You get write access to $allowlist, and read access to everything except for $blocklist".
I'm not concerned about data exfiltration, as implementing it well in a dev tool is too difficult, so my rules are limited to blocking highly sensitive folders by name.
Thank you for sharing a non-trivial working example of a sandbox-exec configuration. Having an exemplar such as what you have kindly shared is hugely beneficial for those of us looking to see what can be done with a tool such as this.
Why? It protects you from someone else (cough updated packages introducing new commands cough) picking a name you already use.
Excluding this argument, overloading system commands is still bad practice lol. Have you ever logged into an embedded device and had a busy box environment? the behaviour of some utilities can be different from what you expect for utilities of the same name.
which <commandname>type -a <commandname>
$ type -a which
which is /usr/bin/which
$ type -a type
type is a shell builtin
type is /usr/bin/type
$ help type
type: type [-afptP] name [name ...]
Display information about command type.
For each NAME, indicate how it would be interpreted if used as a
command name.
Options:
-a display all locations containing an executable named NAME;
includes aliases, builtins, and functions, if and only if
the `-p' option is not also used
-f suppress shell function lookup
-P force a PATH search for each NAME, even if it is an alias,
builtin, or function, and returns the name of the disk file
that would be executed
-p returns either the name of the disk file that would be executed,
or nothing if `type -t NAME' would not return `file'
-t output a single word which is one of `alias', `keyword',
`function', `builtin', `file' or `', if NAME is an alias,
shell reserved word, shell function, shell builtin, disk file,
or not found, respectively
Arguments:
NAME Command name to be interpreted.
Exit Status:
Returns success if all of the NAMEs are found; fails if any are not found.
$ $SHELL --version
GNU bash, version 5.3.9(1)-releasee.g. ls -l -- *
Even when you're not deliberately operating on the commands, it's too easy to get caught out by it with wildcards etc.
I'm not the crazy one here! That's a whole two characters on the same side of the keyboard...
I don’t think it’s a severe security vulnerability. The same thing can happen with $home/bin.
Feel free to add the required ones while reading this comment.
Sorry for the inconvenience this might create.
No inconvenience at all.
Stuff that would not typically raise eyebrows has been made risky. You might cd into less privileged user's $home, or some web service's data directory, and suddenly you've given whoever had access to those users, access to your user.
Maybe you could argue "well, I just won't cd outside of my $home", but the sheer unexpectedness of the behavior seems deeply undesirable to me.
I see Bash only uses commas in Brace expansions:
file{1,2,3}.txt # file1.txt file2.txt file3.txt
I guess it would only be a problem if you want to expand
file,.txt
file,,.txt
file,,,.txt echo file{",",",,",",,,"}.txtIt is both myself and the OSS community which thank you.
Great things are done by a series of small things brought
together.[0]
Please explain the non-explicit suggestion you see, because I don't see it.
It's clear that "adding your script directory in front of the PATH" means a one time edit to .bashrc or equivalent, right? In normal use you're not typing it.