I never did this and never once experienced a name conflict.
Start all of your commands with a comma (2009)
191–200 of 252 posts
Re: Start all of your commands with a comma (2009)
#192Earlier quoted context omitted.
Why does this go wrong and in what situation?
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.
Re: Start all of your commands with a comma (2009)
#193Earlier quoted context omitted.
Why does this go wrong and in what situation?
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.
Re: Start all of your commands with a comma (2009)
#194in vim i am very fond of two mapping prefixes: and ,
they're both so easy to reach for
Re: Start all of your commands with a comma (2009)
#195Tangentially related. Don't ever put "." in your PATH. I used to do this to avoid typing the "./" to execute something in my current directory. BAD IDEA. It can turn a typo into a fork bomb. I took down a production server trying to save typing two characters.
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?
Re: Start all of your commands with a comma (2009)
#196Earlier 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?
I think parent comment means "cp badthing ls" and leave it latent for someone to run. Maybe $PATH has CWD first for convenience?
Re: Start all of your commands with a comma (2009)
#197Earlier quoted context omitted.
On non-English keyboards (Serbian/Croatian/Slovenian, but as they are based on QWERTZ, I imagine German and possibly others too), both "+" and "-" might not require pressing Shift either, and are much better characters than comma.
These are inconvenient for doing anything with the script files except invoking them, because these characters introduce command-line options.
Which was the point here, wasn't it? Script files that you will be commonly running and only editing rarely, I'd optimize for how easy they are to run, not operate other commands on them from within a shell.
Re: Start all of your commands with a comma (2009)
#198I use a different prefix character, e.g. "[", but I have been doing this for years 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 contain…
> I prefer giving scripts numbers instead of names > 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.
"..., I'd visit a doctor"
But I'm not you
Re: Start all of your commands with a comma (2009)
#199Earlier quoted context omitted.
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.
As a native speaker the original comment seemed completely fine, ignore them. Also, I never would never guessed that you weren't also a native English speaker.
Agreed. The commas before the sentence-ending 'too' and 'anyway' were perhaps slightly unusual, but not enough so that I even noticed them, and I don't think either is incorrect. All the rest were perfectly normal.
Re: Start all of your commands with a comma (2009)
#200Earlier quoted context omitted.
That’s true, but I would still call overloading system binaries bad practice. Your making yourself foot gun.
No, in fact he is correct: system scripts won't pick up your overrides configured via your shell's rc scripts.
I said he was right, but in your case you are wrong. Your shell loads thr profile script for login shells, but will load your bashrc regardless of login or not
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.