upvote

points

by the__alchemist9 hours ago |
comments
upvoteby dicytea8 hours ago|
next
[-]
$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.
reply
upvoteby the__alchemist8 hours ago|
parent|
[-]
It is - this is why adding something to the Path is tricky on Linux. Or I should say, there is a mismatch between the common instruction of how to do it (export) vs what you have to do (e.g. edit bash config)
reply
upvoteby hnlmorg6 hours ago|
parent|
[-]
That’s because there isn’t a universal PATH variable.

Env vars are not global. They just have that illusion because a fork() by default will pass your running env vars to the child. Thus trickling that value down.

reply
upvoteby the__alchemist6 hours ago|
parent|
[-]
Exactly. It's annoying if I'm just trying to launch an application I installed by typing its name, which is IMO what PATH is for.
reply
upvoteby hnlmorg5 hours ago|
parent|
next
[-]
How are you installing it? Normally package managers will symlink it into a system defined $PATH directory so you shouldn’t need to faff with $PATH yourself.

Not all applications executable match the application name (eg Visual Studio Code is just “code”). So could that have been the issue?

reply
upvoteby the__alchemist5 hours ago|
parent|
[-]
Depends on the software. Generally, whatever the official installation instructions are.

> So could that have been the issue?

No. Adding things to the path is a reasonably common operation on all OSes and CLI-based software. Sometimes the installer will handle it for you; sometimes it won't. (This may be out of date, but I believe the Rust install script is an example of one that sets it up; Go is one that doesn't, and its official instructions CAO 6 months ago were to use Export, which doesn't work once you reboot)

reply
upvoteby hnlmorg1 hours ago|
parent|
[-]
go install isn’t really an installer. Frankly I don’t really see the point of even having that option.

More broadly speaking, you shouldn’t really be relying on your compiler to do the install. That was never the intended behaviour of a compiler. Which is why history you’d find the install options in the build scripts (eg makefile).

reply
upvoteby arccy5 hours ago|
parent|
prev|
[-]
this is why you don't curl | bash
reply
upvoteby delta_p_delta_x3 hours ago|
prev|
next
[-]
> 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
and for system-wide env vars, it's

  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
reply
upvoteby Lerc8 hours ago|
prev|
next
[-]
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.

reply
upvoteby akoboldfrying8 hours ago|
prev|
[-]
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.

reply
upvoteby 8 hours ago|
parent|
[-]
deleted
reply