Hacker News Reader

Comment by the__alchemist | Hacker News Reader

I wish Linux distros would ship a "Terminal"/"CLI" program etc that is decoupled from the scripting language. Have a universal Path env var that isn't tied to a specific shell. Lets you execute cd commands, launch python/git/cargo/arbitrary applications etc, and have a good bookmark + autocomplete system. It feels like the conflation of scripting language + CLI application is the root of these complications and subtleties.

If you are using shell scripting (And prefer Bash etc over Python), you would keep using Bash/Fish/Zsh etc. If you are using the CLI to launch applications that don't have a GUI, navigate directories and perform file system operations, then you would use the plain terminal.

View on HN

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

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)

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.

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.

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?

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)

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

I was referring to installing the Go compiler - as an arbitrary example of an application you want to be able to launch from CLI, but that doesn't set it up for you. (And instructs (Or did) you to use export.

That’s because go is normally installed via package managers. If you want to install it manually then you need to define the environment manually so that it doesn’t conflict with any system-installed version that might depend on a particular behaviour of the one bundled with the package manager.

Distro maintainers test dependencies across all these different pieces of software, but they cannot test against people randomly installing their own versions of software. So it would be negligent for the Go team to advocate overwriting the distro-tested version of Go

https://go.dev/doc/install

Installing arbitrary software, including through the creator's official instructions, is a core capability of a GPOS.

> people randomly installing their own versions of software.

There are 2 things to unpack: Why you are referring to an official release as "randomly installing my own version", and that installing arbitrary software isn't a core component of a GPOS. Further, what does a call-to-only-use-package-managers (Or did I misunderstand you? That's how I'm reading it) has to do with the PATH on linux being terminal-specific?

> Installing arbitrary software, including through the creator's official instructions, is a core capability of a GPOS.

No, it’s actually not. And when you look at the most popular platforms out there, they do have a primary channel for installing software.

> Why you are referring to an official release as "randomly installing my own version",

It’s not an official release from your OSs package repository. Which is what I actually said.

> and that installing arbitrary software isn't a core component of a GPOS.

I didn’t say that either. I said you’re installing it outside of the package manager so it shouldn’t mess with the platform defaults because it could unknowingly screw up another part of the system that the maintainers are depending on.

If you were to install your own C++ runtime onto Windows and overwrite the Windows default, causing Windows to develop a plethora of bugs. Would you then complain to Microsoft?

This is the equivalent of what you’re doing on Linux and which is why the Go official documentation talks about doing it in a more local scope. Just Google any of the stack exchange and forum discussions around the dangers of updating the system version of Python and Perl. People have done real damage to their systems by overriding the distros shipped version.

> ```Installing arbitrary software, including through the creator's official instructions, is a core capability of a GPOS.

No, it’s actually not. And when you look at the most popular platforms out there, they do have a primary channel for installing software.

```

We have very different ideas of what we want out of an OS! I rarely install applications from package managers because the software I use is usually not on them, or is an out of date version. I don't post my own software on them as I'm not going to register and post updates for each OS. I do not think software should be fragmented across incompatible OS app stores.

> We have very different ideas of what we want out of an OS!

You’re misrepresenting what I said again.

You argued that installing something outside of a package manager is a core requirement for an OS. And I said it isn’t because what you describe isn’t part of the technical definition of an operating system.

Now you’re arguing that I don’t want to be able to load software outside of package managers, and clearly that isn’t something I said. I’m a massively heavy Linux user and a FOSS maintainer. So I very much do install stuff outside of package managers all the time. But the difference between you and I seems to be that I understand any deviations to the host packages need to be installed elsewhere to avoid conflicts with the OS maintainers versions.

> I don't post my own software on them as I'm not going to register and post updates for each OS. I do not think software should be fragmented across incompatible OS app stores.

I do publish my software to multiple different package managers on different platforms. So I understand the problem well ;)

this is why you don't curl | bash

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.

> 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

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 on news.ycombinator.com