151–160 of 177 posts
Earlier quoted context omitted.
But then you start using some tool that expects $0 in the system path and breaks causing frustration and debugging. Pick your poison
In 35 years of using Unix I've never come across anything like this. What tool do you use that this is an issue?
If we could go back to the drawing board I'd say every system utlity should have a verbose name with some kind of aliasing system that provides easy shorthands to them. Then the shorthands could be replaced easily, with the verbose names being used during scripting.
This might seem like a moot point, since we can't go back to the drawing board, but many projects continue to make this problem worse by insisting on naming their binaries like we're still living with the constraints of the 80s. I guess because it gives them the flavour of "real" system utilities. It would be nice if projects stopped doing that, but oh well.
Doesn't work with powershell (which, to be fair, was quite new at the time this blog post was released). But honestly, while 2 or 3-letters aliases are tricky, I've very rarely had issues with 4-letter aliases. There are 456k possibilities. On my small opensuse install, my PATH contains only 105 4-letter executables.
what doesn't work about it? i made ",foo.bar" and i went into PS and typed , and it said: > PS V:\> & '.\,foo.bar'
Earlier quoted context omitted.
I think "comma_nds" ("commands" if you remove the underscore) makes the pun mkre obvious. I didn't get it at first thought, thinking of the .nds file extension for Nintendo DS ROMs.
The pun still holds as "comma,nds" though, and might even do so better.
I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git. One of these names actually collides with a utility that is installed by default on some systems. Doesn’t matter to me. I have my own bin dirs before the system dirs in my path, so mine “win”, and I’m not really interested at all in the tool that mine has a name collision with. If someone were to make a useful to me tool…
Hot take: system commands shouldn't be as accessible as user commands. There should be some sort of namespacing. For example, mkfs should be invoked with `sys::mkfs` or something like that. The line that separates system and user commands may be defined in different ways, and it may be fuzzy in some places, but if a user accidentally invokes a command that they don't even know why is there, and they didn't explicitly…
The sbin directories are supposed to contain "system" (or superuser) commands, and regular users should NOT have those directories in their PATH.
This has been broken for a long time on every distribution I've looked at though.
I was recently poking around ~/.local/bin/ when I noticed that it had dozens of executables that I don't remember putting there. Mostly pyside things, but some other scripts as well. I really had to open each to jog my memory, especially about which scripts I had written myself and which were by other people. The idea about starting my own scripts' names with a comma would have made the job go much faster, and I'm su…
Normally ~/.local/bin/ is only for installed scripts; locally-written ones go in ~/bin/
> The lower-case letters are the very characters used in system commands; brackets, backslashes, the colon, the back-tick, and the single-tick all had a special meaning to the shell Please note that brackets have no special meaning to the shell.
Brackets have a special meaning in the UNIX shell since the earliest times. Together with "*" and "?", the brackets "[" and "]" have been used by the UNIX shell since some of its earliest versions (already many years before the Bourne shell) in pattern matching for pathname expansion (globbing). For example, if you have in a directory 3 files named "file1", "file2" and "file3", then "ls file?" will output file1 file2…
I've used a character for each company I've worked for, and a different one for common scripts. This way is very easy to clean $HOME when I move.
I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git. One of these names actually collides with a utility that is installed by default on some systems. Doesn’t matter to me. I have my own bin dirs before the system dirs in my path, so mine “win”, and I’m not really interested at all in the tool that mine has a name collision with. If someone were to make a useful to me tool…
I tend to make all my git aliases into two-letter combos starting with g. So `gs` is `git status`, for example. Once in a while I actually really need GhostScript though, it’s brilliant for e.g. embedding fonts into PDF files. Usually I then go with `env gs`.
Earlier quoted context omitted.
> then you have to add a shebang line directly to the script itself, which I always feel uncomfortable since it's hard-coded (what if in future I don't want to execute my .py script with `/usr/bin/python` but `/usr/bin/nohtyp`?) > But I really, really just want to run `hello` to call a `hello.py` script that is in my $PATH. On Linux I'd say the shebang is still the right tool for this. If you want a lightweight appro…
> /usr/bin/env is already an abstraction). Isn't that path and the behavior of the binary defined by POSIX though? I thought it's as stable as you can get. That's why it's usually recommended that you use /use/bin/env bash vs /bin/bash in the shebang, as the latter isn't defined by POSIX
I don't see anything about the path being defined. Certainly possible I missed it, though.
I'm not able to check right now but I vaguely recall that I've used a system in the past with env in a location other than /usr/bin.