Follow

hot take:
software should (almost) only have --long-options

(like, ok, -i for input is pretty obvious, but -b for "don't buffer output" needs a proper fucking name, looking at you Plan 9 coreutils, I love the OS around you, but please learn to read long options in those argparse macros)

· brutaldon · 10 · 7 · 11

if people weren't using shortopts everywhere, shell programming would be sooo much easier to learn for beginners

@grainloom I always include long ones by default. Short ones only for simple options that are commonly used.
Am I a visionary?

@ekaitz_zarraga @grainloom
Isn't that best-practice for this sort of thing? (Like, in the GNU style manual even?)

@ekaitz_zarraga @enkiv2 @grainloom
A non-standard thing I love & wish was more widespread is - vs + for flags. I almost always use this format if I'm not using something like getopts that forces the arg prefix to -

@enkiv2 @grainloom Yeah, like in chmod and stuff but chmod is quite disturbing because of the order of the arguments and the style with the numbers and so on.

tar is also one of my enemies

@grainloom I always include long ones by default. Short ones only for simple options that are commonly used.
Am I a visionary?

@grainloom my hot take: if you need the short opts to keep your shell one-liners readable to you, don't write them as shell one-liners, and instead write a bit more in python or something so you can use variable names

@bonzoesc i'm confuse, you can use variables in shells too....
(shoutout to rc for having saner variable expansion rules than sh)

@grainloom oh yeah, totally! but most of the time when i get to the point where i want to turn a one-liner into a script, i usually get to choose the language, and i like ruby more than bash

@grainloom
I don't think it would matter much if the way to look up an option wasn't grepping in a man page. The shell should be an IDE that gives you contextual help and autocompletion.

@freakazoid idk, Zsh has pretty good completion, much better even than any "proper" language I've used
manpage browsing is not that bad in acme, it is much MUCH worse if you only have a single ssh connection to a machine and no terminal multiplexing, so you gotta switch back and forth between man and the script/shell

@freakazoid afaik Fish is even better with this stuff but Zsh is good enough for my Linux system administration needs

@freakazoid @grainloom
Some tools, on some shells, will give hints about args in response to tab complete. I wish (1) this was more common, (2) it was using the same system as command-line help, and (3) it integrated with man pages so you could open up a man page without losing your place in a long under-construction shell one-liner and filter it to only the options relevant to what you're using.

@joeyh @enkiv2
I'm aware of them because some of the tools I use support them. I wish support was much more widespread, and that it also integrated with other forms of online help.

@grainloom but, thanks to history, most… many… some shortopts are POSIX compliant, while most long-opts are not

@a_breakin_glass @grainloom POSIX is supposed to be pronounced like "positive"

the suggestion came from rms

so… i agree.

@grainloom Reminds me of
> command subcommand /argument:value [path.to.file] name.ext;version

Where commands are move, copy, directory, etc. and may be shortened, unless ambiguous, to e.g. dir.

@grainloom Trying to teach my friend. That's a very good point. I will swx to long opts for him.

@grainloom That's how I wrote every shell script at every job I had :
- never rely on parameters orders, instead use long options
- avoid defaults
- print full help on any invalid invocation

I don't know if it's The Right Way, but it sure made my coworkers happy.

@grainloom Yeah, there's a few universal short options that are fine, but for 90% of CLI options, they need a long version.

Universal input options I can think of off the top of my head:

-i for input
-o for output
-a for all
-s for silent
-v for verbose

Unless I'm missing any, these are the only acceptable shortcodes that don't need a long version.

@SoniEx2 @KitsuneAlicia you need version info a lot less though, i don't think it needs a short option, --version is fine

@KitsuneAlicia @grainloom
Do -i and -o make sense to include? We should probably read from stdin & write to stdout in the normal case & expect users to pipe or redirect for any case where a bare filename would seem strange, right?

@SoniEx2 oh. so that's what the quotation marks are for.....

@grainloom

Counter-take, if folks wrote good completion scripts for their apps then it wouldn't matter.

Even hotter take Show more

@grainloom #OCaml programs (Arg module) don't have the distinction: all options start with single dash. And generally they are way easier to parse there, than in C with getopts.

@grainloom it'd be a pain if I had to spell out

ssh --proxy-jump host1 host2

every time, instead of

ssh -J host1 host2

@Wolf480pl what about abstracting it a bit? if you need shorthands, just wrap the executable?
yknow, the same way how modules abstract over / combine other modules

@Wolf480pl but imho there should be a builtin way for executables to complete their arguments, which would make this quicker

@grainloom ... or utilities don't just parse an array of strings that each as to interpret for themselves, and we instead realize that that should be something the shell should take over (so that it can be customized, flags can be aliased or renamed, etc.), while using an universal interface to call binaries.

But goes against the unix philosophy!

@zge
> using an universal interface to call binaries
9p.io/magic/man2html/1/bind

bind -a /my/binaries /bin

flag aliasing indeed seems way too complicated for very little benefit, if you need customization, do it with bind

@zge
this is not something the shell should do, in fact, the shell should do very little
overlay mounts are an OS level abstraction

@zge aliasing flags also would just lead to further confusion, it's like when I mix plan9port and GNU coreutils in scripts, they often take different options or name them differently, and it is confusing
(but these are one-off scripts so I don't care that much)

@grainloom But wouldn't it help you if you could rename flags, so that the gnu and p9p interface could be the same, while the implementation differs?

I'm not saying this is easily implementable in the current shell-binary system, there would have to be a concious reworking of abstractions and interfaces for this to work, but generally I do think an additional layer between a shell (or gui, tui, ...) and a program would be better. char **argv really isn't a good design, imo.

@zge No, I shouldn't actually need both of them. And I should be able to do:
p9p/grep
gnu/grep

but sh can't do that. zsh can't do that either.

the much MUCH simpler rc shell from Plan 9 can.

@zge char **argv is perfectly fine design, it's a way to pass arguments to a procedure. nothing more, nothing less. if you want to combine two procedures, you make a third procedure, just like in every programming language.

@zge
to clarify: `p9p/grep` means "launch /bin/p9p/grep"

@zge this would be something like making a qualified import in Haskell or disambiguating which function you mean when two imported modules export the same name

this kind of forced disambiguation might even be better than Plan 9's overlaying or $PATH hackery on UNIX derivatives

@zge anyways, I hope I don't sound too harsh, I just wanted to point out you are suggesting implementing an abstraction at the wrong level, the shell is not where this should go, but it is easily achievable with a few simple OS level file system abstractions

@grainloom I get the idea, but it has nothing to do with what I was talking about.

I was saying that the idea of passing an array of strings with a variable amount of elements, to a binary for *all* configuration options is bad design. They can have literally any form, it's much harder to enforce consistency, and sometimes splitting at whitespaces just doesn't make a lot of sense.

No properly typed language would allow you to define something like

f(int x, string y, float *a)

but allow you to call it with

f("hans", &f)

but it's up to every single binary to check this for themselves, as they wish. Delegating stuff like this responsibility to the caller would be OS refactoring worth doing, since, if you ask me, this would, not only makes shells easier to use/script, but also easier to integrate system binaries into gui's, especially if IO would be structured/typed.

@zge @grainloom Binaries can't trust user input anyway, so I think the process boundary is exactly the right place to have stringly-typed data.

@clacke @zge Yep. Enforcing correctness is not really the job of an OS. It'd be interesting to see something like a Lisp OS or a Smalltalk environment, but with Idris, but that is not a feasible model for a practical general purpose OS today.
An OS with more granular and user friendly capability management sounds more reasonable.

@grainloom @clacke @zge But this is not just enforcing correctness.

Indeed, it's not even *mostly* forcing correctness.

It's about metadata - if your program operates on an input file and an output file, it would be good to be able to specify that. This would enable a whole suite of new UI.

It would be sad to confine OS development to just things expressible in System V Unix.

@RAOF @clacke @zge Hmmm. On the surface that doesn't sound bad. Buuut I have trouble seeing how exactly it would work.
Could you give an example?

@RAOF @clacke @zge Btw one could build much more modern userspaces on top of 's abstractions.

Sign in to participate in the conversation
Cybrespace

cybrespace: the social hub of the information superhighway

jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal