Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Techniques I use to create a great user experience for shell scripts

nochlin.com

Post reply on HN
Print view View original

81–90 of 281 posts

Re: Techniques I use to create a great user experience for shell scripts

#81

Post by tpmoney »

fragmede wrote: post #69
tpmoney wrote: post #66

Earlier quoted context omitted.

>Try running a 6 month old Python project that you haven't touched and see if it still runs. My experience has been 6 month of python works fine. In fact, python is my go to these days for anything longer than a 5 line shell script (mostly because argparse is builtin now). On the other hand, running a newly written python script with a 6 month old version of python, that's likely to get you into trouble.

argparse? docopt or google-python-fire

argparse, because argparse is built in. I'm usually writing shell scripts to automate some process for myself and my co-workers. The last thing I want is for them to have to be fiddling with installing external requirements if I can avoid it.

Re: Techniques I use to create a great user experience for shell scripts

#82

Post by Hamuko »

xyzzy4747 wrote: post #22

Not trying to offend anyone here but I think shell scripts are the wrong solution for anything over ~50 lines of code. Use a better programming language. Go, Typescript, Rust, Python, and even Perl come to mind.

I draw the line after a single if.

Re: Techniques I use to create a great user experience for shell scripts

#84

Post by nerdponx »

wodenokoto wrote: post #63
AlienRobot wrote: post #53

Earlier quoted context omitted.

Yes. I'd be surprised if exit without parentheses quit the interactive shell when it doesn't quit a normal python script.

Ipython quits without parenthesis.

IPython includes a whole lot of extra magic of various kinds, compared to the built-in Python console.

Re: Techniques I use to create a great user experience for shell scripts

#85

Post by tpmoney »

laserlight wrote: post #71
tpmoney wrote: post #64

Earlier quoted context omitted.

On the one hand, being generous in your inputs is always appreciated. On the other hand, the fact that both exit and quit will terminate ruby means the answer to "how do I quit ruby" now has two answers (technically 4 because `quit()` and `exit()` also work, and if we're talking about "least surprise" if you accept "exit" and "quit", why not also "bye" or "leave" or "close" or "end" or "terminate". Python might be su…

> why not also "bye" or "leave" or "close" or "end" or "terminate". We can include these as well, but each keyword that you include brings diminishing returns at the cost of clutter and inconsistence in the API. Python problematically decides that returns diminish after the first --- “first” according to developers, that is --- possibility in all cases . Ruby anticipates that everyone's first choice will be different…

>Python problematically decides that returns diminish after the first --- “first” according to developers, that is --- possibility in all cases

Eh, that feels pretty arbitrary to me. `quit()` and `exit()` both work, and looking at other languages, `exit()` should almost certainly be your first choice

     C: exit(int)
  Java: System.exit(int)
  SBCL: (quit)/(exit)
    C#: Environment.Exit(int)
   PHP: exit(int)/exit(string)
  Rust: std::process::exit(int)
Having `exit` or `quit` without the parens work might accommodate some people whose first choice isn't to call a function (I guess because they're thinking of the REPL as a shell?), but surely if you're going that far `bye` is a reasonable and practical choice. ftp/sftp use it to this day. At some point you make a cutoff, and where you do is pretty arbitrary. You can like that ruby is twice as lenient as python, but I think it's a stretch to say that python using the single most common function call and a very common alias is "problematic" or even surprising. IMO, python's behavior is less surprising because I don't expect `exit` to be a special command that executes inside the REPL. I expect `exit()` because that's what other programing languages do. And python famously ditched the inconsistent `print "Foo"` syntax in favor of `print("Foo")` in python3 exactly because inconsistency in what was and wasn't a function call was surprising.

Re: Techniques I use to create a great user experience for shell scripts

#87

Post by teo_zero »

kitd wrote: post #86
teo_zero wrote: post #83

In the 4th section, is there a reason why set +e is inside the loop while set -e is outside, or is it just an error?

He says in the article. 'Set +e' prevents any error in a fork blitzing the whole script.

That's clear, my question is why the +e is inside the loop and thus is set at each iteration, while the -e is outside it and thus is set only once at the end.

Re: Techniques I use to create a great user experience for shell scripts

#89

Post by elashri »

bpshaver wrote: post #79
pmarreck wrote: post #57

Earlier quoted context omitted.

Try running a 6 month old Python project that you haven't run in that time and report back. Meanwhile, 10 year old Bash scripts I've written still run unmodified. Winner by a mile (from a software-longevity and low-maintenance perspective at least): Bash

Isn't compare a Python project to a Bash script an unfair comparison? Compare a Python script to a Bash script. If your Python3 script (assuming no dependencies) doesn't work after 6 months I got some questions for you. (And I don't really get how a 6 month old Python _project_ is likely to fail. I guess I'm just good at managing my dependencies?)

Unless you have pinned the exact version numbers in requirements.txt (which you should) or kept you conda/venv..etc around it might be hard. I know at this stage this would be too much compared to what we are talking about regarding python scripts but non-python dependencies are real painful.

I know that this is probably beyond bash scripting vs python scripting but I was just replying to how 6 months project can have problems.

Also not a 6 months scale but the python standard library definitely changes and I would take bash anytime if I have to use venv for running util scripts.

Edit: When python3.8 removed 'time.clock()' it was annoying to change that. I know that it was deprecated since 3.3 (as I remember) but this is the example I have in mind now. But probably it was before I was born that people using

start=$(date +%s%N)

end=$(date +%s%N)

And I will be dead before/if this becomes impossible to use.

Re: Techniques I use to create a great user experience for shell scripts

#90

Post by gjvc »

tpmoney wrote: post #80
jiggawatts wrote: post #39

Earlier quoted context omitted.

> "So no, I don’t want my shell to also have to talk..." What's the point of the shell, if not to manage your databases, your REST APIs, files, and mail? Is it something you use for playing games on, or just for fun? > designed to do one thing well. Eeexcept that this is not actually true in practice, because the abstraction was set at a level that's too low . Shoving everything into a character (or byte) stream turn…

For fun, I took a crack at your example and came up with this craziness (with the caveat it's late and I didn't spend much time on it), which is made a bit more awkward because grep doesn't do capturing groups: netstat -aln \ | grep ESTABLISHED \ | awk '{print $4}' \ | grep -Po '\:\d+$' \ | grep -Po '\d+' \ | sort \ | uniq -c \ | sort -r \ | head -n 10 Changing the awk field to 5 instead of 4 should get you remote po…

put the pipe character at the end of the line and you don't need the backslashes
Post reply on HN