Hacker News Reader

Comment by chubot | Hacker News Reader

GNU utilities have addressed this problem for a long time. Maybe he's on OS X? You can install them there though. You don't need anything like PowerShell.

His

    cut -sf 2 -d \|

can be written

    cut --only-delimited --fields 2 --delimiter '|'

Likewise

    xargs -L 1 -I % jira attach rm %

can be rewritten

    xargs --max-lines=1 --replace=% -- jira attach rm %

These are options are easy to find with cut --help and xargs --help. Or 'man cut and 'man xargs'. (Though honestly it's weird that xargs doesn't accept --max-lines 1, only --max-lines=1 ? )

---

I plan to add a mode to http://www.oilshell.org/ to support longopts in all the builtins, e.g. instead of

    read -r -d ','

instead of

    read -raw -delimiter ','

I wrote a blog post last night that shows other benefits you can try now:

Oil's Stricter Semantics Solve Real Problems http://www.oilshell.org/blog/2019/08/16.html

View on HN

I think it's good practice to always use long arguments in (bash) scripts, for the same reason that a variable named `userLastName` is better than one named `str2`.

Because you mentioned it, PowerShell has a similar readability issue with positional parameters `Set-Content $file $text` vs `Set-Content -Path $file -Value $text`. In many cases the use and order is obvious, but it's not always (and will vary by person), and inconsistent style in code also makes it harder to read.

There's no silver bullet for this stuff. You have to be aware of context and future maintainers: If the vast majority of your code is bash and all maintainers are highly skilled in it, go nuts. If most of your product is in another language and you just have some ancillary install or build scripts in bash/PowerShell/whatever, you should assume people looking at it are closer to the beginner level, and it's better to make things as readable as possible.

It's sad when I found out FreeBSD lacks many of the long options I thought was quite obvious.

mkdir --parents

doesn't work in FreeBSD.

This, plus the fact that a programming language and a command prompt are TWO DIFFERENT THINGS. One is made to be written "once" and then compiled or run many times. The other is a real time interface that should be thoughtful on the amount of effort required by the user to do things, and as such should not take a lot of typing to get things done (and secondarily support scripting).

This is not actually a natural distinction. It's an historical error dating back to OS/360 and JCL (Job Control Language). Fred Brooks, who ran that project, has since claimed it was a mistake.

For examples of languages that excel at quick interaction without the failures of shells, look at Rexx and Rebol. Or power up Smalltalk.

Yup, I've noticed that:

1) It's pretty natural to morph shell (OSH) into something like Python. bash already has anemic arrays and dicts -- might as well give them proper syntax and semantics.

2) Python pretty naturally morphs into something like Java (or even ML / OCaml) with MyPy. I statically typed the whole OSH front end recently and it worked well.

I don't believe in the artificial barriers between interactive and "compiled" languages. Those two things aren't mutually exclusive.

Langauges like C++, Zig, and Jai have Turing-complete interpreters in their compilers. OCaml is normally compiled but it also has a nice REPL that people often use in practice (the type inference helps).

So there is really no reason to think of interpreters vs. compilers as separate. Both of them should be interactive. Your compiler should be infinitely fast.

-----

I probably won't get to this for years, but I can definitely see a path toward making Oil an efficient compiled language. It almost falls naturally out of the odd "bootstrapping" I'm doing.

> I don't believe in the artificial barriers between interactive and "compiled" languages.

Absolutely. Corman Common Lisp was a great example of this. The REPL compiled to efficient x86 machine code.

Yup, I forgot to mention the nice new example of Julia, which is used interactively, dynamically typed, compiles to machine code, and has introspection just like Lisp (e.g. SBCL afaik):

http://www.jlhub.com/julia/manual/en/function/code_native

It's basically a Lisp with syntax, being bootstrapped with femtolisp for its Lisp-like macro system.

https://docs.julialang.org/en/v1/manual/metaprogramming/inde...

Many Common Lisp implementations interactively compile to native code.

"This is not actually a natural distinction"

Doesn't have to be, they overlap a lot, but what I described I feel are two incredibly important distinctions.

So I could read and understand the first example with no issue. At first I was like “yah!” and then as I read on I realized, “yup, your right it is gobbledygook” Then I read this post and said, “chubot you know, you are correct, but I am to old to learn your new fangled —- stuff”.

I cannot tell you the number of times I have mistyped - for — and —- for - over the years without thinking about it. Maybe we should make the command expect both and guess based on what’s after. That would make the CLI better.

Yup, Oil will be like Go's flag parser, and accepts one or two dashes!

The reason most tools don't is that they allow stuff like rm -rf and tar -xvf, rather than rm -r -f and tar -x -v -f. But that seems to be optimizing for the uncommon case now, given how many tools and flags there are. Nobody can memorize them all!

yep. I know about the -- way of specifying the args. I'm not saying that we can't do better with existing tools, just that we don't do better.

I think your post is conflating two questions:

(1) Whether tools support long options, and

(2) Whether script authors use long options

And its claims about #1 seems inaccurate to me. I haven't seen any tools that support only short options in a LONG time. For example, try pip --help or virtualenv --help. Or any tool written in Go, or node.js, etc.

I always support long options myself, e.g.:

https://github.com/oilshell/oil/blob/master/test/sh_spec.py#...

The only case where you don't have long options if you're trying to limit yourself to POSIX, which not many people do, and which I don't recommend for this reason (among others).

-----

I agree with the gist of your post regarding #2 -- people should use long options more.

But there's very straightforward and actionable advice that can go at the very top. They don't have to wait for #1, because it already happened. You can and should just start using them in your bash scripts! You don't need to switch shells, switch languages, or even change the tools you use.

Based on this thread, it DOES appear that many people are confused by this. I'm tempted to write my own blog post, which I may do. But honestly I think a tool that translates short options to long options would be a better solution -- i.e. advocacy through tools rather than advocacy through words. (e.g. "go fmt" seems to have done wonders for formatting without making people read style guides.)

This should be pretty straightforward with the Oil parser [1] and I can use help if anyone cares enough :)

[1] http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par...

In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from the name what it does. definitely a good pattern to just name things what they do.

That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.

I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO.

Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems.

A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.

I don't think the argument has to do with speed of typing; that is a minor concern, since the bottleneck is thinking of what to type in the first place. The issue is the intelligibility of the resulting program. That probably sounds counterintuitive, because people always say that long explicit names make code more readable—but this is only true of code locally. It is not true of programs as a whole. Using long names makes programs longer, as does factoring out subsections into functions and naming those functions. A longer program is harder to understand than a shorter one, and the delta expands non-linearly as system size grows. There's a deep tradeoff here, much deeper than the popular discourse around software development has ever accounted for.

You can see this come up in the OP where the author introduces functions (listAttachment and attachmentInfoLineToAttachmentId) into the example without including their definitions, which would probably double the size of the example.

If you have a rich set of orthogonal, composable primitives, you can do powerful things in a line or two that would require 10x or more code in other environments. The tradeoff is that you have to actually learn the primitives to the extent that you become like a craftsman in a workshop whose tools are all at hand and who can reach for each one as needed without thinking. If you don't know the primitives, of course that line or two will be inscrutable.

IMHO CamelCase is the offender, not the length of the symbol. (CamelCase kills local readability, and therefore global as well) lisp-style-hyphenation is readable to me, even when long. If it helps the code read like prose, all the better.

Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.

Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.

To truly be fast enough not to break the flow of thought->text, it has to (for me) be ~2 tokens ahead of where the cursor is, not completing the current one. And even then I doubt it'd work completely, because it requires rapid context switching to check the completion and pick the right one.

You need a better completion system.

True, but personally, I think this a cost well worth paying for intelligibility and self-documentation. In my opinion, documentation and clarity is more important than maintaining programmer's flow and being economical with command length (and therefore typing time), especially with newer tools that manage a command-line history better. Clear command names pay dividends that outweigh the cost of repeated typing. The dividends come when another person inevitably picks up the shell script you wrote or the documentation you've written to ramp up - and they might not have yet achieved the same level of fluency with the command line. For them these commands might not come pre-integrated.

I would never accept a function in a code review named 'xargs' no matter how much of a short-hand convention it became. I think many company styleguides enforce similar rules for code. Why should command line tools be any different?

xargs and cut do describe what they do.

Only sort of, and cut much more than xargs. in fact, to a newcomer, seeing xargs in a command pipeline would I imagine be completely unintelligible until reading the man pages, as it was to me the first dozen or so times I encountered it.

Reply on news.ycombinator.com