@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
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
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.
@enkiv2 there are argument parsers that also integrate with shell completion. I use http://hackage.haskell.org/package/optparse-applicative
@grainloom but, thanks to history, most… many… some shortopts are POSIX compliant, while most long-opts are not
@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 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.
Counter-take, if folks wrote good completion scripts for their apps then it wouldn't matter.
@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!
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:
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 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
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.
@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.
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.
ｃｙｂｒｅｓｐａｃｅ: 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