Hacker News

Not quoting the tilde doesn't help:

    : tmp; echo $PATH:~
    /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:~

    : tmp; x=$PATH:~
    : tmp; echo "$x"
    /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user

This is almost never what you actually want, and in the rare cases that you do want to store a list, the shell's implicit space splitting usually breaks on filenames containing spaces. Bash has actual array variables which make it possible, but horrible, to handle this in a first-class way:

    : tmp; x=("foo bar" baz)
    : tmp; echo "${x[@]}"
    foo bar baz
    : tmp; touch "${x[@]}"
    : tmp; ls -l "${x[@]}"
    -rw-r--r-- 1 user user 0 Oct 11 17:52  baz
    -rw-r--r-- 1 user user 0 Oct 11 17:52 'foo bar'

In general, whenever you see a $variable $expansion in a shell script outside of double quotes, you should suspect that the shell script will probably fail if your filenames or directory names contain spaces. In very many cases, this results in path injection security vulnerabilities. There are contexts where unquoted $variable $expansion is safe, but they are relatively rare.

However, relevant detail here! One of those safe contexts is actually variable assignment, where as mjmas pointed out in their helpful comment below, unquoted variable expansion is actually perfectly safe:

    : tmp; a='x  y'
    : tmp; b=α:$a:ω
    : tmp; echo "$b"
    α:x  y:ω

I feel like this is common knowledge and should not be worth mentioning. But then it apparently is not common knowledge, as the article proves.

Have I run into this at some point?

I certainly have.

Have I learned to quote better and only where appropriate from it?

I certainly have.

Bourne compatible shells take a while to learn and require some experience. This won't change, but alternatives exist, with their own caveats.

This feature, or at least the syntactic unit in question has a name here "bare words". You also have these in some contexts in Perl and Ruby, YAML, and probably some other languages, idk.

I've also seen this even with people who seem like generally competent shell users. Idrgi

Unless you're running a shell command from python. That was the first time I saw a command string broken down into "string" arguments for every thing like that.

The trick is to quote explicitly and correctly. “ and ‘ are different.

People quote both too often and too little.

GENERAL RULE

1. Double-quote dollar sign expressions, and nothing else.

  foo

  "$bar"/foo

  baz:"$(cat example.txt)"

  exec cmd "$@"

  'Die Hard'

  'ke$ha'

I should point out that the author's example is NOT fixed by different quoting though.

  # original
  export PATH="$PATH:~/.local/bin/"

  # without unnecessary quotes
  export PATH="$PATH":~/.local/bin/

Or just stop using bash. It’s a terrible language to write and has tons of footguns.

You need to read the manual.

I think the appropriate method by POSIX rules would be:

  export PATH="$PATH:"~/.local/bin

Edit: this appears to work properly with mksh on my phone:

  :/ $ export PATH="$PATH:"~/.local/bin
  :/ $ print $PATH
  /product/bin:/apex/com.android.runtime/bin:/apex/com.android.art/bin:/system_ext/bin:/system/bin:/system/xbin:/odm/bin:/vendor/bin:/vendor/xbin:~/.local/bin

Yeah, in scripts I try to be as explicit as possible. `$HOME` for the home directory, `$XDG_DATA_HOME` for `/home/foo/.local/share/`, etc.

The more specific you are, the less gotchas you're going to fall to.

Good decision and avoid the shell whenever you can. Too late for me. I did my fair share of shell programming (and learned if from some real masters) so that my mind is already encumbered. My confidence in being able to write a longer or more complex shell script with 0 errors is still 0, so it gives me nothing.

Looks dangerous to put a user writable directory ahead of system directories in PATH

While we're all getting pedantic and esoteric, in zsh you can do this:

path+=(~/.local/bin)

You don't even have to use the "export" keyword. Not that I would do this, but since we're all pointing out random shell stuff...

(In zsh the lowercase "path" variable is an array that's automatically tied to the $PATH string, so you can just add to it using parens to signify new array elements, separated by a space.)

For various embedded environments that use busybox it's busybox's brand of ash. I generally enjoy the opportunity to learn when bumping up against these kind of edge cases.

> Have a universal Path env var that isn't tied to a specific shell

This sounds like Windows. ;)

Environment variables are stored in the registry; for the user, it's

  HKCU\Environment

  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

$PATH is not tied to any specific shell. And what you're describing is a shell, so I'm not sure how it's any different from existing solutions.

I always thought that there should be a proc style file system for simlinks to user specific data.

I'm not sure why this can't be done. Security people will have a million reasons, I guess it's possible one of them might be valid.

IIUC, you're describing an extremely restricted (some would say underpowered) shell.

It sounds like you could make it yourself in ~10 lines of Python or bash. I don't see it catching on, though.

Perl has been the sysadmin's friend (and enemy) for decades. You can run stuff with backticks and manipulate the results in relative safety.

In every single directory you're ever going to have as cwd when running that software?

Ehh, there are many, many (documented) gotchas about commonly used software that routinely bite people. Yes, it would be great if everyone were an expert in how every aspect of their toolkit works, but that is not practical.

Just maybe, just maybe reserving somethings is not a bad idea... Whatever the fanatics say... There is enough features in shell that maybe banning somethings would be correct design.

If you haven’t quoted it, I think you’re fine.

Afaik it's habit to give system paths precedence so a malicious script can't shadow e.g. sudo and steal your password, escalating a local file write into root

That's standard POSIX.

Tilde expands when at the beginning of an unquoted word.

Pretty straightforward.

  ~ or ~/ --> $HOME

  ~user --> user's home

Bash has a few extra.

  ~+ --> $PWD

  ~- --> $OLDPWD

  ~+N or ~-N --> dirs

https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook

well.. it's in zsh (and probably any other *sh) too

What about people who do not speak English? or even use Latin letters?

If you're trying to avoid headaches then definitely don't allow -. At least not as the first character in a segment.

And allowing any letters from any language is probably worth the hassle.

I always joked about setting a custom keyboard layout to replace the space char with the underscore char specifically for avoiding spaces in file paths.