4 ms·

So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild yo

by h1d 8y ago

So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? You can simply import aliases as is and in some cases, you may be able to even simplify parts of your config. Personally, it was easy for me as I'm administering the servers and it was all just installing fish on every servers. (some dozens.)

squeaky-clean 8y ago
It's not just me, but convincing my team to switch to a new scripting language. Especially if they've never heard of fish and have been using bash/sh their whole careers.
znpy 8y ago
> So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? Absolutely, yes. Because long story short, bash is TriedAndTrue® technology. Stuff that works. It takes a bit of dedication to be mastered at a decent level but it pays off immensely. It's so ubiquitous it is one of those tools that you can learn once, use for the rest of your life, and use in a lot of contexts. It's so widespread that it can bring you very far with very little. All this being said, as someone who used to write code for a living (and now works as a System Engineer, using the bash shell everyday) I must say that if you do not do input verification (according to the language of your choice) and something goes wrong then it's your fault.
- opinionator1 8y ago
  "works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it.
  - robot01 8y ago
    Do you guys have a different, approved shell for prod?
    - opinionator1 8y ago
      Nobody should be using any shell in prod
  - znpy 8y ago
    > Bash doesn't scale. Thanks mate, I had a good laugh. I wouldn't expect bash to scale anyway. That's not what it's meant for. It's meant for system administration task automation. On a more serious note ... In many occasions, the performance you get depends on how you tackle the problem you have, though. Even using bash and the tools from the unix toolbox, sometimes you can gain significant improvements on how you manage your data. Anecdotal: I cannot remember the details, but I remember that rearranging the order of sorting and searching and removing duplicates (sort, sort -u, grep, uniq mainly) I saw a significant speedup. Anecdotal (2): I cut the execution time of a night-running job from hours to minutes (tens of minutes, to be honest - but still less than an hour) just by slicing the size of a problem into smaller parts and by handling each slice in parallel (the machine had 48 cpus, but the problem was being solved "sequentially" on one cpu alone). I wrote some 30-50 lines of python, just to implement parallelism control: the rest of the problem was still handled with bash script. Partial results were reassembled at the end. Bash has coprocesses, so I might have handled that in bash as well, but python was more handy at the time (meh, i just wanted to optimize that problem). What I am trying to say is that sometimes the "scaling" you get is justified by the size of the problem, sometimes it's not.
    - znpy 8y ago
      It's worth noting that bash is really a glue language to call other programs. If you mainly use the tools from the unix toolbox (i'm thinking of grep, for example) you really get the "scaling" (the performance) of native executable code. Again, it really depends on how you handle your data. Having a number of filters chained via pipes is really efficient, for example, when compared with looping over an array and executing some python/perl/ruby one-liners every time.

by h1d 8y ago

squeaky-clean 8y ago

It's not just me, but convincing my team to switch to a new scripting language. Especially if they've never heard of fish and have been using bash/sh their whole careers.

znpy 8y ago

> So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? Absolutely, yes. Because long story short, bash is TriedAndTrue® technology. Stuff that works. It takes a bit of dedication to be mastered at a decent level but it pays off immensely. It's so ubiquitous it is one of those tools that you can learn once, use for the rest of your life, and use in a lot of contexts. It's so widespread that it can bring you very far with very little. All this being said, as someone who used to write code for a living (and now works as a System Engineer, using the bash shell everyday) I must say that if you do not do input verification (according to the language of your choice) and something goes wrong then it's your fault.

opinionator1 8y ago
"works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it.
- robot01 8y ago
  Do you guys have a different, approved shell for prod?
  - opinionator1 8y ago
    Nobody should be using any shell in prod
- znpy 8y ago
  > Bash doesn't scale. Thanks mate, I had a good laugh. I wouldn't expect bash to scale anyway. That's not what it's meant for. It's meant for system administration task automation. On a more serious note ... In many occasions, the performance you get depends on how you tackle the problem you have, though. Even using bash and the tools from the unix toolbox, sometimes you can gain significant improvements on how you manage your data. Anecdotal: I cannot remember the details, but I remember that rearranging the order of sorting and searching and removing duplicates (sort, sort -u, grep, uniq mainly) I saw a significant speedup. Anecdotal (2): I cut the execution time of a night-running job from hours to minutes (tens of minutes, to be honest - but still less than an hour) just by slicing the size of a problem into smaller parts and by handling each slice in parallel (the machine had 48 cpus, but the problem was being solved "sequentially" on one cpu alone). I wrote some 30-50 lines of python, just to implement parallelism control: the rest of the problem was still handled with bash script. Partial results were reassembled at the end. Bash has coprocesses, so I might have handled that in bash as well, but python was more handy at the time (meh, i just wanted to optimize that problem). What I am trying to say is that sometimes the "scaling" you get is justified by the size of the problem, sometimes it's not.
  - znpy 8y ago
    It's worth noting that bash is really a glue language to call other programs. If you mainly use the tools from the unix toolbox (i'm thinking of grep, for example) you really get the "scaling" (the performance) of native executable code. Again, it really depends on how you handle your data. Having a number of filters chained via pipes is really efficient, for example, when compared with looping over an array and executing some python/perl/ruby one-liners every time.