Love this thread reminding me that most experts in computers are unhinged lunatics doing convoluted and tortured things on a daily basis that they consider perfectly normal and even convenient.
Start all of your commands with a comma (2009)
201–210 of 252 posts
Re: Start all of your commands with a comma (2009)
#202yes this is totally cursed but I kinda love the idea
Re: Start all of your commands with a comma (2009)
#203I didn't like the idea. I prefer the alternative approach: _I_ decide the order of dirs in the PATH env. If I introduce an executable with a name, that overrides a system one - I probably do that intentionally. 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…
> 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 `,` 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.
Re: Start all of your commands with a comma (2009)
#204Earlier quoted context omitted.
Somebody mentioned it elsewhere, but it is a security risk: if you end up in a directory that's not under your control, and you do a "ls", it might execute "./ls" instead of /usr/bin/ls, and that can be doing anything, including piping your ~/.ssh/id_* to a remote server. 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 an…
> if you end up in a directory that's not under your control, and you do a "ls", it might execute "./ls" instead of /usr/bin/ls, 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.
Then it's a little bit of a stretch but they could put a script with the name of a common typo similar to commonly run commands there. Maybe "ls-l" without the space in case they miss the space. Yeah, that's a stretch. I went looking for better sources.
> 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.
Re: Start all of your commands with a comma (2009)
#205Earlier quoted context omitted.
Presumably a script that aliases a common thing or something and then it uses the same. E.g. someone adds ./sed that has some default params and calls sed. You’re intended to call it with ~/not-in-path/defaulted/sed and it is supposed to then call sed but instead calls itself if it’s earlier in the path hierarchy. Might even be as simple as “detect if I’m running gnu sed or bsd sed and use the appropriate one”. Obvio…
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 sed binary is in the dir that's to the left of your '.' dir.
Right, that's one way to be half-smart about it. But you have to make sure that's the final thing you append to the path. An easy mistake to make is temporal. You add `.` to the path, and time passes, someone appends `/opt/bin` to the path, and time passes, someone writes `~/not-in-path/defaulted/busybox` that references `/opt/bin/busybox` as just `busybox` and tests it by running `~/not-in-path/defaulted/busybox` while being in `~` and it works so they leave it alone, then you go `cd ~/not-in-path/defaulted/` and run it and die.
"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.
Re: Start all of your commands with a comma (2009)
#206Earlier quoted context omitted.
> That's a poor advice for the scripts you call relatively frequently. Why? It protects you from someone else ( cough updated packages introducing new commands cough ) picking a name you already use.
Because it's useless extra typing. People try to narrow commands down to two fucking chars and you suggest to type the whole goddamn path!
[deleted]
Re: Start all of your commands with a comma (2009)
#207Earlier quoted context omitted.
> That's a poor advice for the scripts you call relatively frequently. Why? It protects you from someone else ( cough updated packages introducing new commands cough ) picking a name you already use.
Because it's useless extra typing. People try to narrow commands down to two fucking chars and you suggest to type the whole goddamn path!
Nobody suggested typing whole paths.
Re: Start all of your commands with a comma (2009)
#208Earlier quoted context omitted.
It used to be very common to "own" a unix system by adding a `ls` binary in some folder and waiting for an administrator to run it.
Why would this own a server? ls lists itself, but listing itself shouldn't cause it to run again? Where's the infinite loop that brings the server down?
They're not talking about the same scenario. Owning isn't denial of service. And they didn't say the `ls` lists things (though it probably will do that at the end).
Re: Start all of your commands with a comma (2009)
#209Earlier quoted context omitted.
The irony in the number of extra commas you've used in this comment...
As a non-native English speaker and writer/typer I'm not well versed in usage of commas unfortunately. Feel free to add the required ones while reading this comment. Sorry for the inconvenience this might create.
This is an example of the difficulty in expressing tone through text. Meant it as a passing lighthearted observational joke.
No inconvenience at all.
Re: Start all of your commands with a comma (2009)
#210A lot of vim users use comma as the leader key so this is probably natural for a lot of folks.
Also seems convenient to be able to type , to autocomplete over your custom commands, in case you forgot the name you assigned them.