[arch-general] package contents on fresh Arch install, like python etc...

[Juha Kankare]

On 21/06/2019 19:45, Eli Schwartz via arch-general wrote:
> On 6/21/19 12:13 PM, Jude DaShiell wrote:
>> Also, man which
>> If you get a chance the linux cookbook will be informative reading given
>> your new position.
> Please do *not* use /usr/bin/which, especially not if you write scripts.
> It is non-POSIX, not portable between different different systems if you
> write scripts, and even on an interactive console where you know you
> personally have the "which" package installed, the results are more
> confusing and less useful than using the native shell introspection.
>
> use `command -v` to find where a command exists, or, in bash, `type -a`
> if you want to see all possible options.
>
> For more details, see:
> https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
> Especially note the "Status today" paragraphs, and if you stubbornly
> wish to continue using "which" despite its well-known pitfalls, then
> carefully avoid any systems where "which" is implemented as a csh script
> (like many commercial Unix systems today).
>
> ...
>
> Use the "conflict" command if you're afraid you may have multiple
> versions of an externally available executable file in your $PATH and
> you want to check where they are and what you're actually using.
>
> Since the common use case of "which" is when you actually want to know
> whether you're using the wrong version of something, the ideal
> interactive debugging tool is "type -a"... but the "conflict" command
> can do one better -- limited to executables and not shell builtins,
> aliases, or functions -- and list *all* conflicting command binaries.
>
Should you always create POSIX-compatible scripts though? All these 
non-POSIX tools were created to ease your job, and you blow them away as 
non-POSIX? If you're creating a single-purpose local script, I think 
it's fair to make it a bash script and use tools which you have 
available on your install, instead of limiting yourself to frankly 
ridiculous workarounds to the shortcomings of POSIX. Just because a tool 
can do anything doesn't mean it can do everything well, or that you have 
enough cognitive capacity at 3 am to write your stupid POSIX-compatible 
shell scripts.

P.S. which is an absolutely terrible command though, modern POSIX 
alternatives are much better for this specific use case.

-- 
Regards, Juha Kankare