2 ms·

Steam horrible bash (and not even sh) scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche

Steam horrible bash (and not even sh) scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). The guys who wrote those are.. "geniuses"... I moved my stuff to /bin a long time ago, but I had to cherry pick stuff in /sbin to please steam stuff. Like you better have nothing in LD_LIBRARY_PATH and everything available via a stable output of /sbin/ldconfig (an abomination). All that to work around the abuse of gnu version names by the glibc devs (and gcc) via a super expensive user/mount namespace kernel mechanism. All that is msft grade, namely mostly bad.

prmoustache 3y ago
Since they will keep a symlink, there is no reason to expect any breakage.
JadeNB 3y ago
> Steam horrible bash scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). sbin is still there, just symlinked to bin. (But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)
- prmoustache 3y ago
  Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
  - JadeNB 3y ago
    > Well you definitely want to use hardcode paths in some scripts. For example those that call sudo. I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.
    - sylware 3y ago
      It is even getting worse, valve, willingly on not, is using it's domination of this market to force into a specific configuration the elf/linux distros (you better have an "expected" output of the glibc /sbin/ldconfig, some libs and modules exactly at the right locations and with the right symlinks), and forces some significantly expensive technical components beyond video game core system interfaces (bash, user/mount linux kernel namespace, niche gnu-only options of commands,etc). Yes, this is mostly bad (msft grade), they should fix all of this. The guys who did that clearly where not the right ones, evil or with an accute lack of perspective and/or experience. First they have to follow ELF specs and certainly not expected "only some ELF specs in some specific way". They should provide clean (10 years old version names, libdl-ing system interfaces, static libgcc, static libstdc++, leave as much as possible of ELF static TLS slots to the system) ELF binaries and depends only on video game core system interfaces: Expecting bash from the user system, certainly not, they could expect a simple SH interpreter and no more (debian dash, busybox ash, etc). They could distribute their statically linked bash interpreter, as they are already distribute a gigantic part of a full elf/linux distro now (their "runtimes"). And this legacy opengl 32bits code... come on, they removed it from macOS, why elf/linux user have to suffer from it (that's actually fishy). Hope valve leaves msft grade mediocrity behind at some point, because for the moment it looks like 1 step forward and 10 steps backward. Oh and video game core system interfaces are: - wayland (code is static in binaries), fallback to x11 (libdl-ing x11 xcb libs). - libxkbcommon-x11 if x11, libxkbcommon if wayland surfaces are using xkb. - vulkan (libdl-ed by design), fallback to opengl (libdl-ed) fallback to CPU rendering. - libasound (alsa-lib) for sound. - linux /dev/input/eventXX device nodes for joypad support. More than that is too excessive and not reasonable.
- abathur 3y ago
  Two thoughts: I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit. --- In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.) The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths. It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.
cryptonector 3y ago
Why expect the worst? Everything should remain backwards-compatible.
7bit 3y ago
Insulting the author of the change request, when it is you who failed to understand the request and how it maintains backwards compatibility is quite strange.

prmoustache 3y ago

Since they will keep a symlink, there is no reason to expect any breakage.

JadeNB 3y ago

> Steam horrible bash scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). sbin is still there, just symlinked to bin. (But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)

prmoustache 3y ago
Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
- JadeNB 3y ago
  > Well you definitely want to use hardcode paths in some scripts. For example those that call sudo. I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.
  - sylware 3y ago
    It is even getting worse, valve, willingly on not, is using it's domination of this market to force into a specific configuration the elf/linux distros (you better have an "expected" output of the glibc /sbin/ldconfig, some libs and modules exactly at the right locations and with the right symlinks), and forces some significantly expensive technical components beyond video game core system interfaces (bash, user/mount linux kernel namespace, niche gnu-only options of commands,etc). Yes, this is mostly bad (msft grade), they should fix all of this. The guys who did that clearly where not the right ones, evil or with an accute lack of perspective and/or experience. First they have to follow ELF specs and certainly not expected "only some ELF specs in some specific way". They should provide clean (10 years old version names, libdl-ing system interfaces, static libgcc, static libstdc++, leave as much as possible of ELF static TLS slots to the system) ELF binaries and depends only on video game core system interfaces: Expecting bash from the user system, certainly not, they could expect a simple SH interpreter and no more (debian dash, busybox ash, etc). They could distribute their statically linked bash interpreter, as they are already distribute a gigantic part of a full elf/linux distro now (their "runtimes"). And this legacy opengl 32bits code... come on, they removed it from macOS, why elf/linux user have to suffer from it (that's actually fishy). Hope valve leaves msft grade mediocrity behind at some point, because for the moment it looks like 1 step forward and 10 steps backward. Oh and video game core system interfaces are: - wayland (code is static in binaries), fallback to x11 (libdl-ing x11 xcb libs). - libxkbcommon-x11 if x11, libxkbcommon if wayland surfaces are using xkb. - vulkan (libdl-ed by design), fallback to opengl (libdl-ed) fallback to CPU rendering. - libasound (alsa-lib) for sound. - linux /dev/input/eventXX device nodes for joypad support. More than that is too excessive and not reasonable.
abathur 3y ago
Two thoughts: I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit. --- In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.) The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths. It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.

cryptonector 3y ago

Why expect the worst? Everything should remain backwards-compatible.

7bit 3y ago

Insulting the author of the change request, when it is you who failed to understand the request and how it maintains backwards compatibility is quite strange.