5 ms·

It's funny how this community trash on JS at every chance they have but for some reason bash is off the hook. I am tired on seeing CI pipelines failing and Live

It's funny how this community trash on JS at every chance they have but for some reason bash is off the hook. I am tired on seeing CI pipelines failing and Live environment crashing because typos in .sh scripts. I propose to switch to powershell every time I can but that still sounds as heresy for the devops guys.

crabbone 4y ago
Lol... You are going to switch to PowerShell in initramfs? PowerShell is just another Perl / Python / Ruby. Except made by Microsoft, so it's got a ton of useless features, lacking some essential stuff and has bombastic syntax. It's not suited for the role of UNIX Shell. Not by a long shot. ---- On a larger note, the whole idea of needing a shell is bad. It comes from a defective (or rather overly simplistic and un-insightful) design of UNIX. A better system wouldn't need a distinction between a system programming language and a shell. You would just use one and the same thing for both purposes. If you are on Linux, Guile is supposed to be that, but... maybe it was supposed to be that?.. I'd still want it to take the role of Shell, even though it doesn't tick all my boxes.
- Kwpolska 4y ago
  Nobody said anything about switching to PowerShell at the lowest levels. But even though it is verbose, and has some annoying quirks (like over-eager unpacking of one-item arrays), it's much nicer to write scripts in. You don't need sed/awk to parse output of ls and hope it's stable, just get whatever data you need from the object. What essential stuff is missing?
  - nailer 4y ago
    > hope it's stable Or worse, the output is stable (because peopleare scraping it with aws and sed) and reflects things as how they existed 20 years ago versus now. For example `ifconfig` doesn't really match how Linux does networking.
    - crabbone 4y ago
      Ifconfig is not part of the shell. Whatever your grudges with ifconfig are, however justified, they have nothing to do with how the shell works. BTW, I don't know of any distro wit LTS releases that didn't yet expire that doesn't ship with iproute2. In my opinion, iproute2 has done a very good job, given the circumstances to organize and systematize information about networking. So, if you don't like ifconfig, today you most likely have a better alternative.
      - nailer 4y ago
        Your comment seems to have f the point. I know ifconfig isn’t part of bash and I’m aware of ip addr but the point stands: people don’t update tools because it breaks scraping. If fact if they did ip addr wouldn’t exist: we’d be able to update ifconfig.
        crabbone 4y ago
        > people don’t update tools because it breaks scraping. What people are you talking about? Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. It doesn't happen because of someone's whims... If some individual user chooses to stick with an outdated system: it's on them, and they have no ground to stand on if they complain about it... > we’d be able to update ifconfig. No we wouldn't. "ip a" is a tiny fraction of what this command does. The reason it came to be was not that ifconfig needed replacement, but because Linux utilities are a zoo of halfbaked projects, most of which have huge flaws in their design, especially when it comes to extensibility. Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? What about IB? What about sr-iov etc.? -- Nope, and since there wasn't a single structured and systematic tool, that could've been extended by the authors of eg. bridge drivers, they were forced to come up with their own tools, eg. brctl. iproute2 wasn't an improvement on top of ifconfig. It was an aggregation and systematization of various tools and configurations that dealt in a very partial way with various aspects of networking. There would've been no way to keep any kind of backwards compatibility with ifconfig, so there was no reason to keep the name. It's not an evolution of ifconfig, it's an entirely different thing.
  - crabbone 4y ago
    I've been writing Shell scripts for... well, over ten years at this point. I don't believe I've ever parsed output from ls. Definitely not with sed or awk. I don't think that any Linux admin worth their salt would do that. Needless to mention that neither ls nor sed nor awk have anything to do with Shell. > What essential stuff is missing? Since Microsoft tried to replace not just the shell, but the entire set of utilities with PowerShell, they forgot about xargs, for example. But, if we are talking about the shell proper, then things that are missing would be a serialization format that would allow one to pretend that remote shell sends "objects" rather than strings. Most importantly, however, PowerShell is an attempt to fix the problem at the wrong level. The reality of the OS it's running on is that processes take command line and environment variables, and they don't take objects. They return exit codes and two or more output streams, they don't return objects. PowerShell is trying to pretend that communication between processes happens in objects, but that's a lie, and it shows. In any non-trivial use of such a shell, you will have to escape the objects, and face the reality of what's happening underneath. That's why earlier in the days, when objects were a novelty programmers thought that a programming language that is object-oriented from the bottom up is preferable to the one which implements objects as a library. PowerShell is even worse in this sense than Perl or Common Lisp. Objects in PowerShell aren't an afterthought. The authors wanted them from the start, but couldn't have them. Unfortunately, we live in the world where most popular projects we use today were still-born in engineering terms (eg. Unix, and later Linux, any Fortran-like language created since 80's etc.) So, it may as well happen that PowerShell will succeed in terms of popularity, but it's broken by design unless we completely replace the whole way we work with processes... and I don't see it happening unless there's some cataclysmic event that wipes most of us out.
    - Kwpolska 4y ago
      > Since Microsoft tried to replace not just the shell, but the entire set of utilities with PowerShell, they forgot about xargs, for example. You can just use foreach with an array or a multi-line string: $newFiles | foreach { git add $_ } > Most importantly, however, PowerShell is an attempt to fix the problem at the wrong level. The reality of the OS it's running on is that processes take command line and environment variables, and they don't take objects. They return exit codes and two or more output streams, they don't return objects. PowerShell is trying to pretend that communication between processes happens in objects, but that's a lie, and it shows. In any non-trivial use of such a shell, you will have to escape the objects, and face the reality of what's happening underneath. If you’re executing processes, then yes, things might get hairy. But if you’re using PowerShell cmdlets (which either do the thing natively, or call a subprocess and parse it to an object), the object-oriented stuff is really convenient and powerful. Here’s a random example of fancy PowerShell things. How can you do this (filter by a keyword, group by parent directory, and sort the results by count) with UNIX tools? What magic combination of ls, find, sed, grep, awk, sort, uniq would solve this? Get-ChildItem -Recurse C:\Stuff | Where-Object {$_.FullName -notmatch "xyz"} | Group-Object Directory | Sort-Object -Descending Count
- deleted 4y ago
  [deleted]
aeyes 4y ago
You aren't going to write 100k lines of shell scripts but you might reach this amount of code in JS projects so we should rightfully hold the language to a higher standard. Shell scripts are just glue and unless they get huge they are easy to understand, modify and maintain. I have a fair amount of shell scripts in CI pipelines and things usually break when we hit unhandled edge cases which is exactly what I would expect. That said, if your script is for a single platform you won't need any of these hacks which only exist for compatibility with different/older shells. My scripts won't even run on bash 3 and I accept that.
- eviks 4y ago
  Except they are not "easy to understand, modify and maintain" because of a bunch of weird bugs like the one from the article, and they don't depend on the script size
  - Spivak 4y ago
    Whether or not a language is weird is just a function of how comfortable you are with the quirks. You could fill a textbook with just the unintuitive hacky shit you had/have to do in JS.
    - mypalmike 4y ago
      Esoteric languages (e.g. brainfuck, befunge) are evidence that language weirdness is somewhat measurable and objective.
Pxtl 4y ago
PowerShell will happily run scripts with misspelled variables and not fail until it hits the invalid line, if it ever does. It's not like it's statically typed or something.
nirvdrum 4y ago
Most people don't like shell scripting, it's just that it's way easier to maintain the environment. A shell script from 20 years ago will likely still run without dealing with EOL runtimes or ensuring you're running an LTS version of a shell. The shell is quite stable from an API perspective, so you're not dealing with removal of deprecated features. Shell scripts largely run the same across different systems. With the notable exception of Apple shipping an ancient version of Bash, rarely do I have to care what version of a shell a system ships with. And that only matters if I want to use new Bash-specific features. While shells can and do have security issues, much of that is historical and given the smaller surface area they just have fewer security issues than say, Node. I don't need a shell version manager à la NVM, virtualenv, or rbenv. I don't need to worry about a massive dependency graph. A shell of some sort comes pre-installed with every *nix system I've ever used so I don't need to worry about figuring out how to install a new runtime in an unprivileged environment. I'm sure some people love Bash and love shell scripting. For many of us it's just a matter of practicality.

crabbone 4y ago

Lol... You are going to switch to PowerShell in initramfs? PowerShell is just another Perl / Python / Ruby. Except made by Microsoft, so it's got a ton of useless features, lacking some essential stuff and has bombastic syntax. It's not suited for the role of UNIX Shell. Not by a long shot. ---- On a larger note, the whole idea of needing a shell is bad. It comes from a defective (or rather overly simplistic and un-insightful) design of UNIX. A better system wouldn't need a distinction between a system programming language and a shell. You would just use one and the same thing for both purposes. If you are on Linux, Guile is supposed to be that, but... maybe it was supposed to be that?.. I'd still want it to take the role of Shell, even though it doesn't tick all my boxes.

Kwpolska 4y ago
Nobody said anything about switching to PowerShell at the lowest levels. But even though it is verbose, and has some annoying quirks (like over-eager unpacking of one-item arrays), it's much nicer to write scripts in. You don't need sed/awk to parse output of ls and hope it's stable, just get whatever data you need from the object. What essential stuff is missing?
- nailer 4y ago
  > hope it's stable Or worse, the output is stable (because peopleare scraping it with aws and sed) and reflects things as how they existed 20 years ago versus now. For example `ifconfig` doesn't really match how Linux does networking.
  - crabbone 4y ago
    Ifconfig is not part of the shell. Whatever your grudges with ifconfig are, however justified, they have nothing to do with how the shell works. BTW, I don't know of any distro wit LTS releases that didn't yet expire that doesn't ship with iproute2. In my opinion, iproute2 has done a very good job, given the circumstances to organize and systematize information about networking. So, if you don't like ifconfig, today you most likely have a better alternative.
    - nailer 4y ago
      Your comment seems to have f the point. I know ifconfig isn’t part of bash and I’m aware of ip addr but the point stands: people don’t update tools because it breaks scraping. If fact if they did ip addr wouldn’t exist: we’d be able to update ifconfig.
      - crabbone 4y ago
        > people don’t update tools because it breaks scraping. What people are you talking about? Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. It doesn't happen because of someone's whims... If some individual user chooses to stick with an outdated system: it's on them, and they have no ground to stand on if they complain about it... > we’d be able to update ifconfig. No we wouldn't. "ip a" is a tiny fraction of what this command does. The reason it came to be was not that ifconfig needed replacement, but because Linux utilities are a zoo of halfbaked projects, most of which have huge flaws in their design, especially when it comes to extensibility. Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? What about IB? What about sr-iov etc.? -- Nope, and since there wasn't a single structured and systematic tool, that could've been extended by the authors of eg. bridge drivers, they were forced to come up with their own tools, eg. brctl. iproute2 wasn't an improvement on top of ifconfig. It was an aggregation and systematization of various tools and configurations that dealt in a very partial way with various aspects of networking. There would've been no way to keep any kind of backwards compatibility with ifconfig, so there was no reason to keep the name. It's not an evolution of ifconfig, it's an entirely different thing.
- crabbone 4y ago
  I've been writing Shell scripts for... well, over ten years at this point. I don't believe I've ever parsed output from ls. Definitely not with sed or awk. I don't think that any Linux admin worth their salt would do that. Needless to mention that neither ls nor sed nor awk have anything to do with Shell. > What essential stuff is missing? Since Microsoft tried to replace not just the shell, but the entire set of utilities with PowerShell, they forgot about xargs, for example. But, if we are talking about the shell proper, then things that are missing would be a serialization format that would allow one to pretend that remote shell sends "objects" rather than strings. Most importantly, however, PowerShell is an attempt to fix the problem at the wrong level. The reality of the OS it's running on is that processes take command line and environment variables, and they don't take objects. They return exit codes and two or more output streams, they don't return objects. PowerShell is trying to pretend that communication between processes happens in objects, but that's a lie, and it shows. In any non-trivial use of such a shell, you will have to escape the objects, and face the reality of what's happening underneath. That's why earlier in the days, when objects were a novelty programmers thought that a programming language that is object-oriented from the bottom up is preferable to the one which implements objects as a library. PowerShell is even worse in this sense than Perl or Common Lisp. Objects in PowerShell aren't an afterthought. The authors wanted them from the start, but couldn't have them. Unfortunately, we live in the world where most popular projects we use today were still-born in engineering terms (eg. Unix, and later Linux, any Fortran-like language created since 80's etc.) So, it may as well happen that PowerShell will succeed in terms of popularity, but it's broken by design unless we completely replace the whole way we work with processes... and I don't see it happening unless there's some cataclysmic event that wipes most of us out.
  - Kwpolska 4y ago
    > Since Microsoft tried to replace not just the shell, but the entire set of utilities with PowerShell, they forgot about xargs, for example. You can just use foreach with an array or a multi-line string: $newFiles | foreach { git add $_ } > Most importantly, however, PowerShell is an attempt to fix the problem at the wrong level. The reality of the OS it's running on is that processes take command line and environment variables, and they don't take objects. They return exit codes and two or more output streams, they don't return objects. PowerShell is trying to pretend that communication between processes happens in objects, but that's a lie, and it shows. In any non-trivial use of such a shell, you will have to escape the objects, and face the reality of what's happening underneath. If you’re executing processes, then yes, things might get hairy. But if you’re using PowerShell cmdlets (which either do the thing natively, or call a subprocess and parse it to an object), the object-oriented stuff is really convenient and powerful. Here’s a random example of fancy PowerShell things. How can you do this (filter by a keyword, group by parent directory, and sort the results by count) with UNIX tools? What magic combination of ls, find, sed, grep, awk, sort, uniq would solve this? Get-ChildItem -Recurse C:\Stuff | Where-Object {$_.FullName -notmatch "xyz"} | Group-Object Directory | Sort-Object -Descending Count
deleted 4y ago
[deleted]

aeyes 4y ago

You aren't going to write 100k lines of shell scripts but you might reach this amount of code in JS projects so we should rightfully hold the language to a higher standard. Shell scripts are just glue and unless they get huge they are easy to understand, modify and maintain. I have a fair amount of shell scripts in CI pipelines and things usually break when we hit unhandled edge cases which is exactly what I would expect. That said, if your script is for a single platform you won't need any of these hacks which only exist for compatibility with different/older shells. My scripts won't even run on bash 3 and I accept that.

eviks 4y ago
Except they are not "easy to understand, modify and maintain" because of a bunch of weird bugs like the one from the article, and they don't depend on the script size
- Spivak 4y ago
  Whether or not a language is weird is just a function of how comfortable you are with the quirks. You could fill a textbook with just the unintuitive hacky shit you had/have to do in JS.
  - mypalmike 4y ago
    Esoteric languages (e.g. brainfuck, befunge) are evidence that language weirdness is somewhat measurable and objective.

Pxtl 4y ago

PowerShell will happily run scripts with misspelled variables and not fail until it hits the invalid line, if it ever does. It's not like it's statically typed or something.

nirvdrum 4y ago

Most people don't like shell scripting, it's just that it's way easier to maintain the environment. A shell script from 20 years ago will likely still run without dealing with EOL runtimes or ensuring you're running an LTS version of a shell. The shell is quite stable from an API perspective, so you're not dealing with removal of deprecated features. Shell scripts largely run the same across different systems. With the notable exception of Apple shipping an ancient version of Bash, rarely do I have to care what version of a shell a system ships with. And that only matters if I want to use new Bash-specific features. While shells can and do have security issues, much of that is historical and given the smaller surface area they just have fewer security issues than say, Node. I don't need a shell version manager à la NVM, virtualenv, or rbenv. I don't need to worry about a massive dependency graph. A shell of some sort comes pre-installed with every *nix system I've ever used so I don't need to worry about figuring out how to install a new runtime in an unprivileged environment. I'm sure some people love Bash and love shell scripting. For many of us it's just a matter of practicality.