8 ms·

> bash is just fine (yes, it is) No, it's not. It's 2020, we need to stop it with the stringly-typed, footgun-filled madness that is bash scripting. We deserve

• montroser 6y ago
  I think you are forgetting that serious operators do not have spaces in their paths.
  • hk__2 6y ago
    *People who are used to work with bad tools don’t have spaces in their paths.
    • tenebrisalietum 6y ago
      "C:\Documents and Settings" still hurts after all these years.
      • linuxftw 6y ago
        "C:\Program Files(x86)". Who ok'd that?
        • GrinningFool 6y ago
          I haven't looked in a while, but last I checked you could also still get to it via C:\PROGRA~1? (This was years ago, that might have been 'fixed'?)
          • joombaga 6y ago
            These are called 8.3 filenames. They're a filesystem feature. They're still created by default in Windows 10 on NTFS, but can be disabled or stripped using `fsutil`.
        • einarin 6y ago
          Speculation, but I suspect that Microsoft explicitly put both user data and programs in paths with long filenames and spaces to help force software to support those things. That always seemed like a good thing to me, it's ridiculous that we still have software that breaks on paths with spaces.
        • oblio 6y ago
          It's a design decision and a good one, at that. Forcing 1 million developers to handle spaces properly while they spend 1 billion hours developing their software is preferable to 1 billion regular users having to remember to not use space, a perfectly good separator, in their 1 billion billions hours of usage of said software.
      • jedieaston 6y ago
        It still hurts today, because Microsoft puts a space between your first and last name in your profile if you are using a local account but not for a domain account, which causes all kinds of weird issues if you ever have to use cmd.exe...
    • jdxcode 6y ago
      cough make cough
  • ironmagma 6y ago
    That’s just objectively false.
  • jdxcode 6y ago
    "Serious operators" never want to put their files into iCloud Drive? They must be using butterflies then https://xkcd.com/378/ https://xkcd.com/378/
    • paulchap 6y ago
      "Serious operators" probably use a cloud storage solution that supports WebDAV/FTP/SFTP, like box.com or Google Drive - "real operators", on the other hand, have a self-hosted solution (-; And IMHO relying on iCloud for essential data storage probably isn't a good idea.
      • pnutjam 6y ago
        rsync or btrfsync for the win
      • jdxcode 6y ago
        I find iCloud much better than Google Cloud and I'm pretty sure I qualify as a "serious/real operator" any way you want to call it. I have no time or interest in hosting a custom solution. And I certainly have no need for FTP. But even if I wasn't experienced, quit this gatekeeping crap. Let people use the tools that work for them. It does not in any way reflect on how "serious/real" they are.
        • paulchap 6y ago
          > "Serious operators" probably use a cloud storage solution that supports WebDAV/FTP/SFTP, like box.com or Google Drive - "real operators", on the other hand, have a self-hosted solution (-; I didn't mean to discredit you for using iCloud - if it came across that way, I apologize. My original comment was meant to be tongue in cheek. I've got to admit that I'm a bit gob-smacked by your reaction... After all, my comment was similar in structure to yours. I even quote unquoted the terms, and the "real operator" part was a reference to the editor war xkcd you mentioned. Taking your post literally, I could accuse you of doing the same thing by assuming that real operators were Mac users. And I'm sure there are many use cases where hosting your own cloud storage would be absurd. But, re-reading my comment, it didn't read like a flame war instigating piece of propaganda "Calling all real sysops to arms against the user threat. Grab your cattle prod, fellow comrades, and crank up the voltage!" > And IMHO relying on iCloud for essential data storage probably isn't a good idea. I don't condone gatekeeping (although, to be perfectly honest, I don't see how my comment could be interpreted as elitist. It's not like the learning curve for GDrive or any other solution with a better cross platform support is _that_ high), but I don't see a reason why I shouldn't voice my opinion on a tool, even if responding to something obviously meant as a joke. Of course you're free to use iCloud. Personally, I wouldn't feel comfortable with the thought of my critical data being stored on a platform that, historically, hasn't always been known for being extremely stable. Maybe I'm just biased. If you feel comfortable using it, then use it. I won't stand in your way.
  • teddyh 6y ago
    On the contrary, serious operators write programs to handle spaces in the paths.
  • geofft 6y ago
    I don't know about "serious," but trustworthy operators use tools that work correctly in the presence of weird states because they take responsibility for their work instead of blaming others.
• tempodox 6y ago
  When I open `av` in vim, shellcheck spits out 167 warnings. This is not written robustly.
  • xyzzy_plugh 6y ago
    FWIW shellcheck complains about many false positives.
    • gravitas 6y ago
      But in this case, their code is comparing strings to ints like on line 126: while [[ "$#" -gt 0 ]]; do Spot checking code for basic bash mistakes like this tends to tell me the quality of the code overall, as these are basic mistakes. $0.02
      • hk__2 6y ago
        If $# is a number, aren’t "$#" and $# exactly the same in Bash? Enclosing things in double quotes doesn’t change their type, since everything is already treated as a string. https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html https://www.gnu.org/software/bash/manual/html_node/Double-Qu...
        • pizza234 6y ago
          It's true, but you're semantically overloading the variable syntax (by hinting that it's treated as string). Plus, left and single operands, in bash conditions, don't require quoting, so a lean style is actually not to use them at all.
          • tempodox 6y ago
            > …left and single operands… That's false: x='foo bar'; [ $x = 'foo bar' ]; echo $? -bash: [: too many arguments x='foo bar'; [ "$x" = 'foo bar' ]; echo $? 0
• dastx 6y ago
  Can't say anything about this tool, but compared to ansible, bash is mostly fine. In my opinion ansible is a (and pardon my language) clusterf* of a tool compared to the alternatives. Certainly, if bash had the likes of inventories, roles and other features to make maintenance and reuse easier, I'd choose that over ansible.
  • p_l 6y ago
    Ansible is writing bash scripts in YAML, templates using system that doesn't grok YAML and causes parsing errors due to whitespace, interpreted by schizophrenic Python that might be 2 or it might be 3. ... I guess pure bash might be better.
    • pnutjam 6y ago
      you can run pure bash from ansible, either by copying a script or using the shell module: examples: both with sudo ansible all -m shell -a "hostname" -b ansible all -m script -a "script=/home/user/myscript.sh" -b I love to throw together a quick inventory list and run adhoc ansible commands against a bunch of servers.
    • partdavid 6y ago
      I have my issues with Ansible, and I'm really not a fan of "templated YAML"-based tools, which has been an unfortunate trend that's not limited to Ansible (GCDM and helm share this problem). But if you're writing a lot of bash scripts into your plays you're probably doing it wrong.
• __MatrixMan__ 6y ago
  Yes it is. If you have two type systems and you don't want them to interact, gluing them together with stringly typed bash is a good way to keep their scope small. As a user interacting with multiple programs by different authors, that's a very common use case. Giving your type systems boundaries is a good idea. The alternative tends towards one-type-system-to-rule-them-all, an idea that Russell thoroughly explored in the early 1900's, Godel proved to be unmaintainable in the 30's, and that everybody except the Java and C# crowd has since abandoned as a dead end.
  • woah 6y ago
    It is a pretty sloppy and archaic language. We need an updated version that keeps the string typing and inline execution of external binaries, but has modern syntax, plus a few more conveniences and guardrails.
    • __MatrixMan__ 6y ago
      I was only taking issue with the objection to string typing. I totally agree that the rest of bash requires a bit of stockholm syndrome to love. I haven't yet taken the time to play with it but I'm hoping www.oilshell.org addresses some of the warts.
    • partdavid 6y ago
      You might be interested in Powershell. I used bash for 20 years and considered myself an experienced user and programmer with it. Comparatively, my experience with Powershell is relatively short, but I switched to it and the first time I needed to handle a piece of structured data I was hooked and haven't looked back.
      • pnako 6y ago
        I recently discovered Powershell, in a Windows context. It's weird, but has interesting ideas, and is better than bash for sure. Supposedly it supports Linux, but I haven't actually tried.
• _jal 6y ago
  > No, it's not. Then come up with something better. It will need the same or better ease-of-use for non-programmers, should function as a shell (so that their everyday use also teaches them scripting), with the same flexibility that lets people who don't care about typing or other fancy programmer stuff and just need to get work done. If your first instinct is to say "python", you don't understand the problem.
  • linuxftw 6y ago
    While I agree with the sentiment that bash is not the solution for an ansible-like thing, I also agree with what you're saying. I consider myself an accomplished system engineer and software developer. I use bash all the time. Not writing bash scripts is like saying not to use the terminal, it's just cacophony.
  • q3k 6y ago
    You are misunderstanding or misrepresenting what I said. If it wasn't obvious, I meant that bash scripting is not okay _for this sort of complex work/projects_.
    • rejatak 6y ago
      Hello
    • _jal 6y ago
      I fail how to see how I could be doing either. "[W]e need to stop it with the stringly-typed, footgun-filled madness that is bash scripting" is pretty categorical.
    • scrooched_moose 6y ago
      On paper I agree with you, but that has not been our experience in practice. Bash "just works" with some very well understood limitations. Every one of these "better" solutions introduces 10x the complexity with 10x the limitations (always undocumented). After spending dozens of hours configuring them thanks to terrible documentation, generally taking multiple support tickets (if there's anyone to talk to at all), we get it working. Then, after using it for a period of time, they fall flat on their face in far worse ways than bash. Granted I'm only managing hundreds of servers, not thousands or more, but more often than not a for i in {000..199}; do ssh machine$i "some command"; done is more reliable, with better error handling, than all of the other solutions. Edit: As long as linux/unix maintains the "everything is a (plaintext) file" approach, I have trouble picturing a better solution than text/string based interface like Bash. You can build more front-end complexity on top of it, but you're always going to end up back in the same place.
• 0x8BADF00D 6y ago
  > No, it's not. It's 2020, we need to stop it with the stringly-typed, footgun-filled madness that is bash scripting. Ansible is written in Python. You could make the same argument.
  • sk0g 6y ago
    How? Python has an actual type system. A programming language that does strings for everything would be, for example, PHP.
    • 0x8BADF00D 6y ago
      Python has dynamic typing, which can be equally dangerous. In fact I’d argue it’s more dangerous. You will not throw errors until runtime, which will literally blow up in your face.
      • ironmagma 6y ago
        So does Bash, though.
        • sk0g 6y ago
          And Bash does not support static typing at all, unlike Python. Not sure what their argument even is.
          • ironmagma 6y ago
            Python doesn't support static typing either unless you're using mypy which is experimental. Bash and Python both however have strong types, although Bash's are weaker than Python's.
        • 0x8BADF00D 6y ago
          Right, but Python gives you the illusion of safety. And the person I was replying to was trying to dismiss this interesting Ansible alternative because it was written in a language he doesn’t like.
• ThePhysicist 6y ago
  Ha, Ansible parses and 'executes' YAML files using Python, but not before passing them (repeatedly?) through a template library (Jinja2) originally designed to produce HTML pages. They even came up with a way to write for loops in YAML... What I'm trying to say is that sometimes great software is written using (in some people's opinion) terrible technology. Not everything needs to be written in idiomatic Haskell or Rust. Personally I have to say that I started writing more bash scripts again recently, I even wrote one that interfaces with the GPIO ports on a Raspberry Pi. Works like a charm, is concise and (I find) also quite readable: https://gist.github.com/adewes/7a4c20a5a7379e19d78ba54521d3dc7d https://gist.github.com/adewes/7a4c20a5a7379e19d78ba54521d3d... But then again I'm also a person who enjoys Perl, so maybe it is time for me to be banished to a lonely island :D
  • lux 6y ago
    Perl was great for encouraging that kind of thinking with the old motto "there's more than one way to do it". I'm glad I started with Perl because it's helped me think about solutions I may have otherwise dismissed. Bash is far from perfect, but it's readily available at many people's fingertips, and it gets you to some solutions really fast. This is cool.
    • deleted 6y ago
      [deleted]
  • the_mitsuhiko 6y ago
    > originally designed to produce HTML pages Jinja2 can produce HTML pages, but it was never exclusively designed for that. In fact one of the earliest uses of Jinja2 was generating LaTeX.
    • ThePhysicist 6y ago
      I stand corrected, didn't know that!
• ufo 6y ago
  I don't really mind the string typing of Bash. Shell commands, their arguments, and their outputs are all strings anyway so it makes sense to give special treatment for strings. That said, features such as word-splitting are terrible footguns that only exist because of the burden of backwards compatibility. Hackernews, what other languages do you suggest as Bash replacements that doesn't have as many opportunities to shoot yourself on the foot? This is an area that I never found something I truly liked. A lot of people suggest Python for this kind of task but when I have a small script that is mostly doing pipelines and command substitutions with "$()" then the python version with subprocess is much more verbose.
  • acemarke 6y ago
    There's a wonderful library called `plumbum` [0] that lets you execute external binaries and capture output using Bash-like piping syntax, while preserving all the goodness of Python's syntax and flow control. Highly recommended. [0] https://plumbum.readthedocs.io/en/latest/ https://plumbum.readthedocs.io/en/latest/
  • Too 6y ago
    Are you really really really doing mostly pipelines and command substitutions? Most of the time when opening a script with such claim there is maybe one pipe that makes sense and all the others are just things like cut, grep and awk to trim of any trailing newlines. Substitutions are usually from things like date. All of things that are easier to manipulate in a typed language.
• forty 6y ago
  With bash at least I don't have to read the documentation each time I want to create a file or anything else...
• deleted 6y ago
  [deleted]
• peterwwillis 6y ago
  > We deserve better than this. What have we done to deserve better? Have you seen a community of people working on a bash scripting replacement lately? Has it hit HN? Does it have the same confluence of features, convenience, portability, simplicity, and utility that bash scripting has? If so, why aren't we using it yet? The fact is, we all use bash because it's the best we have for what we really want to do. Bash is what we deserve. 31 years of "good enough".