Re: Default PATH setting - reduce to something more sensible?

On 24.01.2025 22:38, Dan Cross wrote:

In article <vn0cno$29vrs$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

On 24.01.2025 14:33, Dan Cross wrote:

In article <vmvp3d$2671i$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

On 23.01.2025 23:46, Keith Thompson wrote:

[snip]
For this and other reasons, though you *can* have a literal ~ in $PATH
in bash, it's best to avoid it and use $HOME instead.

>
Or use it correctly, unquoted and unescaped.

>
Or just don't use it, and then you don't have to worry about it.

>
But as a Ksh (or any non-Bash shell) user I don't have
to worry about it. (Why shall I see any issue with it?)

 
Because you might want to put whatever you assign to `PATH`
in quotes, for instance if their are spaces in one of the
component pathnames (people run `bash` on windows and all
kinds of weird places) and the behavior differs.  $HOME is
pleasantly boring by comparison.

Sure. That's why you can write, say,

PROJECT_PATH="Yet another space odyssey"
PATH=~/bin:"My Windows Bin":$PROJECT_PATH:'/tmp/$LITERAL':.

(The standard way. Clean unambiguous quoting. No issues.)

 

[snip]
But more importantly; shell programmers shall be well aware
of what quotes mean in shells! They are not just fancy things
or accessories that one may or may not use as one likes. They
have clear semantics and are essential in shell programming.
>
If you want tilde-expressions expanded _don't quote them_.

 
What if the expression refers to a file name with a space in
it?  Of course, one can escape the whitespace characters in
filenames, but that gets tedious.

The (standard-)rules are simple and clean; see my sample above.

To say it explicitly; values in variables are *not* subject to
another word-splitting in assignments [in standard shells].

Janis