3 ms·

> 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

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

by JadeNB 3y ago

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.