Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Start all of your commands with a comma (2009)

rhodesmill.org

Post reply on HN
Print view View original

171–180 of 252 posts

Re: Start all of your commands with a comma (2009)

#171

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #11

I 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 have zero problems with the terseness of the k language, the names of the source files nor the source code they contain

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"
That might make sense if I was using the scripts to communicate with a another person, or if I intended other persons besides me to use the scripts

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

Re: Start all of your commands with a comma (2009)

#172

Post by necovek »

zelphirkalt wrote: post #121
jkercher wrote: post #78

Tangentially 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.

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 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.

Re: Start all of your commands with a comma (2009)

#173

Post by aidenn0 »

ahepp wrote: post #157
nh2 wrote: post #141

Worth pointing out that with Nix/NixOS this problem doesn't exist. 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…

The "solution" of only ever using full absolute paths works on any unix system, doesn't it?

Yes with a but:

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).

Re: Start all of your commands with a comma (2009)

#174

Post by necovek »

layer8 wrote: post #87
ndsipa_pomu wrote: post #12

I appreciate the idea, but the comma just looks horrible to me as part of a filename. I can imagine someone unfamiliar with the naming scheme to get confused. 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 meanin…

Underscore requires pressing Shift, however. > 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? ;)

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.

Re: Start all of your commands with a comma (2009)

#175

Post by layer8 »

necovek wrote: post #174
layer8 wrote: post #87

Earlier quoted context omitted.

Underscore requires pressing Shift, however. > 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? ;)

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.

Re: Start all of your commands with a comma (2009)

#176

Post by aidenn0 »

ablob wrote: post #146
nh2 wrote: post #141

Worth pointing out that with Nix/NixOS this problem doesn't exist. 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…

So if I want to use grep in a small script, do I have to write: /nix/store/grep-hash -flags files | /nix/store/head-hash instead of: "grep -flags files | head"?

If it's a one off, you just use something like "nix shell" to add it to your path for running the script.

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)}"
Then I use "$GREP" in the script itself, and develop with grep in my path, but it's trivial to prepend all of my dependencies when I bundle it up for nix.

1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/no...

Re: Start all of your commands with a comma (2009)

#177

Post by wasmainiac »

mathfailure wrote: post #9

I 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 would recommend against overriding standard system binaries, you could break compatibility on your system with scripts that depend on those binaries. I just use an abbreviation like rg=“grep -RE”

Re: Start all of your commands with a comma (2009)

#178

Post by aidenn0 »

Arcuru wrote: post #148
xyzzy_plugh wrote: post #140

Earlier quoted context omitted.

https://github.com/nix-community/comma

I'm not sure I'll ever understand why they replaced their working ~50 line shell script with a Rust program that just shells out to the same nix-* commands. I appreciate that there are some safety benefits, but that program is just not complex enough to benefit.

Shell is already memory safe, so there's not even "we replaced C" to lean on.

Re: Start all of your commands with a comma (2009)

#179

Post by hinkley »

mathfailure wrote: post #9

I 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…

When “I” means me then this usually works for me. But when “I” becomes “we”, sometimes this goes off the rails because someone introduces a bin with breaking changes that silently fucks up projects that dev doesn’t really know about, or forgot about.

Call it the Chesterton’s Fence of ‘which’.

Re: Start all of your commands with a comma (2009)

#180

Post by RadiozRadioz »

wasmainiac wrote: post #177
mathfailure wrote: post #9

I 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 would recommend against overriding standard system binaries, you could break compatibility on your system with scripts that depend on those binaries. I just use an abbreviation like rg=“grep -RE”

Why are those scripts running in interactive login shells? If they are influenced by the configuration of profile, then the scripts are bad.
Post reply on HN