Hacker News Reader

Comment by Neil44 | Hacker News Reader

I got excited when I saw the 'f' and 'count' commands, but they're just scripts he has on his system. Like doing grep 'plover' blah.log | cut -d ' ' -f 11 | sort | uniq -c | sort -n. Personally I'd prefer to use the ubiquitous commands that work everywhere than rely on having custom scripts on my system, but they are nice.

View on HN

Most people who use Unix directly build up some stuff in ~/bin (often a misnomer because it's shell scripts and not binaries, although mine is less of a misnomer than most because so much is in C rather than shell). The trick is to build them out of the standard portable components that exist everywhere. (This means, among other things, no #!/bin/bash.)

You shouldn't be using `#!/bin/bash` but rather `#!/usr/bin/env bash` instead.

I know this but usually don't do it. Been burnt by it too. Reprogramming your brain is hard.

[edit] Would there be any negative consequences to having an automated process go through and change it? Maybe the size difference might cause some issues with some things doing black magic with data in the file.

sed 's| no | not only |'

/bin/bash won't usually ship with a BSDish OS because of the license, so it is not generally portable to use bash-isms. (HPUX, IRIX, SunOS, Solaris, etc. I don't reckon would have had bash either)

Not to mention once installed on a BSD it would most likely reside in /usr/bin/bash (OpenBSD for instance)

Or /usr/local/bin/bash (on FreeBSD).

I disagree.

You are also right.

Now that I saw tingletech comment I got your point :)

That's the whole point of shell scripting, to take a series of minimal programs and tie them together into something that does a more complex task. There's no reason to distrust a shell script simply because it is a script any more than there is to trust a binary simply because it's a binary.

Sure, but relying on custom shell scripts as unix primitives can be problematic if you find yourself frequently managing/troubleshooting systems that you don't own, and you don't want to (or aren't allowed to) put those handy scripts in place. Then when you're on any given system, you forget whether you can use "f", or if you have to fall back on awk.

I think it's less about not trusting custom scripts than it is about ensuring that your unix muscle memory doesn't atrophy.

I agree 100% with you.

I spend a lot of time moving around different machines, processes, configuration files, logs, etc. And I stopped maybe 10 years ago to use anything that is not available on a base system.

I don’t use fancy shells, I don’t use aliases, I don’t write local shortcut scripts, etc.

I just use regular bash, combine base utilities in one liners, and live with it.

Maybe I loose 1s here and there when writing one liners compared to someone with a library of wrapper utilities. But that gives me an immense benefit: I am at home on any machine, any distribution, everywhere, without any configuration, with any user.

There's always something like Ansible (or even a lower-tech solution) to at least give you the basic toolset that helps you double or triple your performance.

> that helps you double or triple your performance.

Sure, in a quest of productivity, I should also use Vagrant and Packer to create docker images with a development environment so that I can run Serverless troubleshooting containers on all my machines.

These scripts will surely help me triple the performance of my bash one liners.

I’ve heard Eclipse has good shell completion and support for oh-my-zsh too.

> if you find yourself frequently managing/troubleshooting systems that you don't own

You start thinking about packaging.

Packaging what?

I would be mad at any admin that would dare to deploy his helper shell scripts like “addup” and “count” on a machine other than his laptop.

And if you meant he could just have these things in his home, then it defeats the purpose of the original comment: trouble shooting and administering machines forces you to often switch user, machine, etc.

If a company has recurring troubleshooting issues, eg. "we need to know which process is taking all the CPU/RAM/IO", why wouldn't they add a script when they provision their machines with puppet or whatever tool they use?

Then instead of having to remember how to check all these things, they just run "find_resource_hogs.sh" and voila. It also enables other people to troubleshoot without specific knowledge.

Of course you don't want to put anything in there just because it might save 10 seconds, but then https://xkcd.com/1205/

That’s the theory but frankly the syntax is so cumbersome, irregular and needs so many googling for "easy" things like conditional, substring, etc. that I now use a real programming language if a script needs to be anything more than a list of commands without any logic (besides variables substitution).

> That’s the theory but frankly the syntax is so cumbersome, irregular and needs so many googling for "easy" things like conditional, substring, etc. that I now use a real programming language if a script needs to be anything more than a list of commands without any logic (besides variables substitution).

You are basically describing modern programming.

Script Language (or scripting) is a programming language.

And about the "real" programming language you can also trap yourself googling and installing yet another library (did you read the code?) and/or reimplementing existing tools from the unix programming environment.

You are overly pedantic on a detail point that doesn’t matter: yes shell scripting is technically a programming language, but my point is that it is a terrible one worth ditching for any non trivial task. Perl was created precisely more than 3 decades ago to address this problem. Nowadays there are alternatives such as Python, Powershell or even scripting wrapper for compiled languages (such as C#) that allow to do the same job very well, with less surprising behavior and that can be refactored later more easily.

I disagree with you wholeheartedly and without condition. Not only are you discounting how much time it takes to learn how to program effectively in a real 'glue' language you are high handed in ignoring the ubiquity, working archive and efficacy of a shell script. Not to mischaracterize but I find this type of attitude most frequently in 'lead' individuals with less than 10 years experience: typically 20's and 30's in age. I'm curious if this is your case?

Shell may be super useful to learn but that doesn't mean it's full of horrible footguns that greatly hamper your ability to determine if your code is doing the right thing or not once you get to a significant body of code: just take a look at https://mywiki.wooledge.org/BashPitfalls and compare with other languages that don't have some of the more egregious easy-to-make mistakes (e.g. anything to do with word splitting).

I agree, and as TFA mentions, shell scripting is an "incoherent mess of composable paraphernalia" where you have to memorize a “weird mishmash of trivia” -- but if you have memorized it, then you can do some neat stuff without a so-called "real" language installed (that you have to upgrade and have to worry about if you have a modern version installed)

Instead of doing

    grep 'plover' blah.log | cut -d ' ' -f 11

I usually do

    awk '/plover/{print $11}' blah.log

Less typing, but probably not as easy to understand.

> [...] but they're just scripts he has on his system. Personally I'd prefer to use the ubiquitous commands that work everywhere than rely on having custom scripts on my system [...]

Is okay for one to have their own tools.

  $ f() { printf "\$%s" "$1"; }
  $ echo a b c | awk '{ print $(f 2) }'

His system is not very different from mine or yours. He just chose to combine the tools in a specific way.

Reply on news.ycombinator.com