[HN Gopher] The growth of command line options, 1979-Present (2020)
___________________________________________________________________
The growth of command line options, 1979-Present (2020)
Author : intrepidhero
Score : 130 points
Date : 2021-12-15 16:22 UTC (6 hours ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| woodruffw wrote:
| Maybe it's because I'm not the biggest Unix purist, but I don't
| really mind the proliferation of command line options. The two
| things that _do_ irk me are:
|
| * Using short options in scripts. Scripts should almost always
| use long options. As a corollary, tools should _always_ provide
| long options _unless_ the tool isn 't intended for scripting.
|
| * Lack of discoverability. We still don't have a standard way to
| ask an arbitrary tool which flags it supports, or for a rough
| semantic mapping of those flags (e.g. the classic -v/-V verbose
| and version confusion). Developing a standard here would go a
| long way towards automating things like tab completion without
| each tool needing to maintain _N_ scripts for _N_ shells or
| having its own slightly-different `--completions=SHELL`
| generator.
| Symmetry wrote:
| For tab completion the fish shell just parses the man pages,
| which are fairly standard, to figure out what tab completions
| are available.
| RMPR wrote:
| I also used to think that, but it seems like the advanced
| parsing is done manually[0]
|
| 0: https://news.ycombinator.com/item?id=29343053
| nauticacom wrote:
| The last point would be amazing, imo. It's unfortunate that,
| because of history, commands accept and parse arbitrary strings
| as input instead of formally specifying it like a function
| signature + docblock. If I could rewrite the universe, commands
| would use a central API for specifying the names, data types,
| descriptions, etc. for all the input they take. In our
| timeline, maybe some file format could be standardized that
| describes the particular inputs and options a command takes,
| and e.g. shells would hook into it. Kind of like header files,
| but distributed either in a community repository or by each of
| the tools themselves.
| useerup wrote:
| > ... commands accept and parse arbitrary strings as input
| instead of formally specifying it like a function signature +
| docblock. If I could rewrite the universe, commands would use
| a central API for specifying the names, data types,
| descriptions, etc. for all the input they take
|
| Which is _exactly_ what powershell does: Commands in
| powershell (called "cmdlets") are like functions with type
| hints. A command does not parse the input strings itself,
| rather it exposes this type information to the shell. The
| shell is the one responsible for discovering the parameters
| (and types) and parsing the command line parameters and
| coercing types before passing them (strongly typed) to the
| actual command.
|
| This means that the information about parameter names and
| types is readily available for doc-generation, auto tab-
| completion and language servers which allow syntax
| highlighting, completion etc to work even inside editors such
| as vscode or emacs.
|
| The point is that to specify a cmdket you _must_ declare
| parameters, in much the same way that for a function in a
| programming language to accept parameters it must declare
| those as formal parameters.
| kaetemi wrote:
| Sounds a bit like PowerShell.
| woodruffw wrote:
| Yeah, the inertia is the real killer here. I'd love to see a
| fully embedded solution (particularly given that ecosystems
| like Go and Rust discourage sidecar files like manpages), but
| thus far the only one I've really seen is individual tools
| supporting a `--completions=SHELL` style argument that spits
| out an `eval`-able script for the requested shell.
|
| The real dream would be some kind of standard way for a
| program to indicate that it's opting into more intelligent
| CLI handling _without_ any execution. I 've thought about
| trying to hack something like that together with a custom ELF
| section, but that wouldn't fly for programs written in
| scripting languages.
| laurent123456 wrote:
| > Using short options in scripts
|
| And documentation, or when answering questions. SE answers are
| often like "just type `blah -jraiorjg` and you're done", which
| means having to look up all these options in the manual. Short
| options should be the exception, when working in the shell
| mostly, not the rule.
| citrin_ru wrote:
| Re-typing commands from SE answers without consulting a man
| is a bad idea even with long options. SE is a good place when
| you don't know where to start or which man to read, but once
| you see an answer it is better to check in mans/docs how
| suggested command would work and what it will do. But I agree
| that if you want to help someone who doesn't know particular
| command it is better to use long options.
| hulitu wrote:
| > Ironically, one of the reasons for the rise in the number of
| command line options is another McIlroy dictum, "Write programs
| to handle text streams, because that is a universal interface"
| (see ls for one example of this).
|
| That is unfortunately not the reason. There are 2 main reasons
| why today (GNU) command line utilities have a lot of options: 1).
| GNU. Apparrently they like to add features to programs 2).
| Herritage of SYSV/BSD. Traditionally BSD options were different
| from SYSV and the new GNU utilities were made to understand both.
| fsckboy wrote:
| > _1). GNU. Apparrently they like to add features to programs_
|
| unix comes out of "worse is better". GNU comes out of The Right
| Thing.
| seoaeu wrote:
| Adding features isn't itself a bad thing. But when you cannot
| iterate or remove features (even the smallest change to
| existing functionality could break a script somewhere!) then
| you end up with the jumbled mess we have.
| avgcorrection wrote:
| I don't see an argument from you that (1) _wasn't_ caused by
| the point that Luu raises.
|
| It's not strange to end up adding features to programs if the
| effective IPC is so impoverished that you would need to
| sandwich a bunch of repetitive formatting commands if you
| _didn't_ add some convenient built-in formatting options.
| munificent wrote:
| Two of the many joys in life are:
|
| 1. Having a problem and solving it with a small amount of effort.
|
| 2. Having a mental model of some external thing and delighting in
| seeing that your model is accurate with respect to the actual
| thing.
|
| Elegant, minimal systems excel at providing #2. Big sprawling
| systems with lots of options and special cases excel at providing
| #1.
|
| Many software engineers seem to be calibrated to extract a lot
| more joy from experiencing #2 than #1. It's probably something to
| do with the nature of the work. We work "backwards" by having a
| mental model of a thing we wish existed and then bring it into
| being. If we didn't find deep satisfaction in harmony between our
| mental model and software model, we wouldn't have the drive to
| keep fixing all of the bugs in our software.
|
| But there is nothing _instrinsically_ superior to the joy of #2
| compared to #1. It 's just a psychological/emotional preference.
| Many people, if not most, outside of the world of software
| engineering seem to prefer #1. They just like to get stuff done
| and make stuff happening. You rarely see woodworkers lamenting
| about the variety of clamps, jigs, and tools they have. Instead,
| they delight in finding just the right specific tool to make a
| job easy. Fishermen love their tackleboxes.
|
| Of course, there is an appreciation of #2 in all of us, and you
| see minimalism everywhere. But I've never seen it raised to such
| a religious, moral level as I see in software engineering. It's
| important to remember that that's a psychological choice we're
| making--a personal preference we impose--and not something
| fundamental to systems.
| avgcorrection wrote:
| This is very insightful.
|
| Number 1 can be efficient but it isn't satisfying if it was
| taken straight from a cookbook.
|
| > But there is nothing instrinsically superior to the joy of #2
| compared to #1. It's just a psychological/emotional preference.
|
| I'm not sure about that. Feeling mastery and competence is
| intrinsically rewarding. And that's easier to achieve with
| point number 2; if your mental model aligns more with the real
| thing then you are less likely to make mistakes and to have to
| look up reference material--you are less likely to get
| estranged from the task at hand.[1] And you are less likely to
| be bewildered by all the apparent complexity that surrounds you
| and that the sage old ones just tell you to put up with and to
| not question. I don't think you would even mind being less
| efficient as long as you are in that sweet groove of point
| number two.
|
| [1]: Modernity + alienation: efficient misery.
| andy_ppp wrote:
| Yes, the things we derive satisfaction from are because of
| our ability to slot things into a preexisting framework,
| proving our opinions correct (which we all love to happen)
| and releasing dopamine (probably). There is no such thing
| from applying a specific special case from a piece of
| software.
| avgcorrection wrote:
| I guess you could put it like that.
| munificent wrote:
| _> Number 1 can be efficient but it isn't satisfying if it
| was taken straight from a cookbook._
|
| That may be true to one degree or another for you, but isn't
| universal. I also prefer to understand solutions (why pick #1
| or #2 when you can have both?), but I have certainly been
| happy to see a problem evaporate even if I'm not 100% certain
| why. The result has its own value.
|
| _> I'm not sure about that. Feeling mastery and competence
| is intrinsically rewarding._
|
| Yes, we all experience #2. My point is just that it's not
| intrinsically superior to other sources of joy. Preferring it
| is just that, a preference. There's nothing morally wrong
| with people who prefer to simply get things done, nor is
| there something fundamentally flawed with complex software
| that caters to that.
| albertzeyer wrote:
| Out of my experience, #2 is often superior over #1 though.
|
| For some limited well understood context, well defined
| application, well defined task which will not be extended later
| and only lots of variations are needed, then yes, #1 is
| probably better. It's nice to have options like
| enable_fancy_feature=True.
|
| However, in practice, you often have none of these. The context
| is often not well defined. It's often not yet well understood.
| The application is not well defined, neither the specific
| tasks. The scope and tasks will likely be extended during the
| development.
|
| In that case, it can often turn out that you made the wrong
| abstractions, wrong options in case of #1. The software itself
| becomes more and more complex and becomes very hard to
| maintain, and new things which should be simple are now
| difficult to do because of too much interdependencies.
|
| Now, an elegant minimal system, or collections of small
| building blocks or tools, will turn out to be much more
| effective in solving some new task later on.
| wyager wrote:
| > Big sprawling systems with lots of options and special cases
| excel at providing #1.
|
| This is the sales pitch, but in reality you spend so much time
| configuring and debugging that you rarely actually save any
| time.
| munificent wrote:
| _> in reality you spend so much time configuring and
| debugging that you rarely actually save any time. _
|
| Conversely, that's the sales pitch for minimalism. But the
| reality is that well-intentioned, thoughtful designers and
| users seem to end up spending most of their time building and
| using systems with a lot of complexity. If it really ended up
| costing them more time to use those systems, it begs the
| question of why we keep building them.
| marttt wrote:
| Interesting table. One more column would be great, though: number
| of flags for all these commands in Plan 9 or 9front.
| pif wrote:
| Nothing more than a load of garbage.
| simiones wrote:
| The article, or the growing command line options list?
| munk-a wrote:
| The comment since it lacks any context and presents nothing
| but a vague opinion. It's actually a recursive comment
| because the poster heard that programmers love recursion.
| WalterBright wrote:
| Every command line switch is a bug.
| WalterBright wrote:
| Far too often, when people cannot agree on how a program should
| work, the "solution" is to add a switch and so avoid making a
| decision.
| z3t4 wrote:
| A better option is to create a common library and then make
| many programs
| kelnos wrote:
| Or the program should legitimately work in both ways, at
| different times, depending on context and the user's current
| needs. Sometimes I want `ls -t`, sometimes I want `ls -S` and
| sometimes I just want plain `ls`. It would be silly to make
| them three different programs, and if those options didn't
| exist, that would be foolish.
|
| Sure, you could say that `ls -t` should be `ls | sort
| --time`, and if command output was structured rather than
| just text, and standardized, that would work and be easy to
| implement in a cross-tool manner. But now we have `sort
| --time`, which is _also_ an option that you say shouldn 't
| exist. So now what? `ls | timesort` and `ls | sizesort`?
| That's just silly.
|
| Ok, how about something that doesn't affect _how_ the output
| is presented, but _what_ output is presented. Most of the
| time I just want `ls`, but sometimes I want to see dotfiles,
| so I have `ls -a`. How do we fix that? `ls` and `lshidden`?
| Again: silly. Do we just say "dotfiles are stupid; we
| shouldn't have this artificial concept of hidden files"? No,
| that's silly too.
|
| I get that your follow-up post softens the absolutism with
| "far too often", but your original post did assert that
| "every" command line option is a bug, and I'm tired of this
| "options are bad" argument. Overall I would rather have the
| option to change behavior than not. Take those options away,
| and we get complaints that the maintainers are dumbing things
| down and removing choice.
|
| It's really a no-win situation: either your software is
| bloated, or it's not flexible enough. Few people agree on
| where the happy medium is. Discussions about this are, IMO,
| just tiring and pointless, and are some of the worst forms of
| bike-shedding. The only reason a potentially-useful option
| should be removed (or not added in the first place) is if the
| option creates a maintenance burden that the maintainer is
| not comfortable taking on.
| WalterBright wrote:
| > but your original post did assert that "every" command
| line option is a bug, and I'm tired of this "options are
| bad" argument.
|
| Every option doubles the amount of testing required to
| exhaustively test the program. This soon reaches the level
| of impossibility. My point is to encourage people to take a
| hard look at the options and consider redesigns and
| specification changes to eliminate as many as one can.
|
| The same applies to `if` statements in code. Finding ways
| to change the data structures and program logic to
| eliminate edge cases and the `if` cases is a significant
| goal of mine.
|
| It also applies to compiler warnings. In the case of C, the
| warnings are there because the C Standard allows practices
| that are known to cause many problems, but the C compiler
| vendor has to compile them anyway, and so choose to make
| them warnings. But for a newer language, the warnings come
| about because the language designer did not design the
| language rules well enough.
| bcbrown wrote:
| > Every option doubles the amount of testing required to
| exhaustively test the program.
|
| True, but pairwise-independent combinatorial testing
| provides almost-exhaustive coverage with non-exponential
| growth in test cases: https://github.com/microsoft/pict
| useerup wrote:
| `ls | sort --time` is very close to `ls | sort
| LastWriteTime` which is how you would do it in PowerShell.
|
| In PowerShell `ls` is only used for retrieving the
| filesystem objects (files and directories). It does not
| have options for sorting or formatting[1]
|
| Sorting is generally handled by `sort` (alias for the Sort-
| Object cmdlet).
|
| Formatting is generally handled by one of the format
| commands, like format-table (alias `ft`) or format-list
| (alias `fl`) or by converting into another format like e.g.
| json or xml through `convertto-json`.
|
| I.e. if I want to display the full path of every file
| sorted by descending by last access, I would write:
| ls | sort -d LastAccessTime | select fullname
|
| [1] except for the `-name` switch which is more of an
| optimization which only retrieves the local name as string
| objects.
| marcodiego wrote:
| A graphic showing this growth would be super interesting.
| 908B64B197 wrote:
| With Python installed everywhere I often question the logic
| behind writing long or non-trivial shell scripts.
|
| It always seems so brittle since the output of a command line
| tool can change (unless it's frozen in some standard) and relies
| way too much on regex and assumptions about what the data
| returned will look like. I much prefer to keep bash around only
| for interactive commands and ad-hoc one-liners.
| kjellsbells wrote:
| Some observations: - Tool options increasing
| monotonically seems like the very definition of bloat. Probably
| since the marginal cost of adding an option is very low and the
| cost of removing an option is very high (angry users). -
| There's a cognitive cost to bloat. Personally, I know maybe 5-10
| options to all the commands in the regular *nix tool set and
| that's about the limit my brain could hold. - Options are
| useless if they are not discoverable at lower mental effort than
| the alternatives. Man/info pages are great, but I'm not wading
| through multiple pages on the off chance that ls has an option
| that can output in JSON if it's a Wednesday and my POSIX locale
| is unset. Discoverability is a serious problem in large systems,
| and I'm not sure anyone knows what the solution is. I mean, we've
| had google, Stack Overflow, man X intro, GNU info, ...
|
| So what does that mean in practice? Is there a way to square
| modernity with the UNIX philosophy? I would suggest that
| 1. Tool authors ruthlessly restrict options to fit in the working
| set memory of the average human user. Let's say <10 options. If
| you need more options, you need a new tool. 2. Tools are
| pluggable, so that the base implementation is simple and known-
| to-be-present (shades of POSIX here), but that there is a
| expansion pack mechanism for people who need it. Imagine DLC for
| ls. You want extra magicka in your find(1)? Make sure you have
| the plugin and off you go. 3. Tools designers and users are
| clear about the decision criteria to *not\* use a specific tool.
| Sure I could do crypto in awk, or parse \0 in ls, but I shouldn't
| do so. There's no shame in reaching for a better solution, and,
| over time, solutions will coalesce into new tools. For example,
| everyone uses jq not awk to parse their JSON...right?
|
| Edit: I just returned from my kitchen with a IRL example: my
| dishwasher has 15 programs but only two buttons show any sign of
| wear: "quick wash" and "start"...
| intrepidhero wrote:
| This got linked in another front page story. Uncomfortable Truths
| in Software Engineering.
|
| > The Unix philosophy of "do one thing well" doesn't actually
| work that well. Dan Luu explains this better than I could.
|
| Usually The Unix Philosophy gets nothing but praise in these
| parts so I was interested to see a counterpoint.
| xxpor wrote:
| I mean the empirical evidence alone seems point at the Unix
| Philosophy not actually being popular in practice. GNU tools
| are much more widely used on boxes humans interact with than
| BSD/busybox. You don't see everyone trying to figure out how to
| install all of the suckless tools immediately after installing
| linux, etc. And then of course we get into systemd and that
| whole ball of wax.
|
| I do think there's a growing split between server like things
| and desktop like systems that people actually regularly use.
| For example, Alpine is super popular in containers, not so much
| on desktops. Same thing with Busybox, but that's more
| explicitly meant for embedded envs.
| throw10920 wrote:
| > I mean the empirical evidence alone seems point at the Unix
| Philosophy not actually being popular in practice. GNU tools
| are much more widely used on boxes humans interact with than
| BSD/busybox.
|
| I think that I can present an even better piece of empirical
| evidence (not to diminish the poignancy of your own):
|
| Almost no large or successful piece of software is composed
| of Unix command-line utilities.
|
| Firefox, Linux, gcc, Visual Studio Code, Windows, Chrome,
| Google services, Discord, Spotify, Blender, GIMP, Apache,
| Slack, Office, Steam, Matrix/Element...almost every single
| non-trivial piece of software in existence is _not_ composed
| out of Unix shell utility pipelines.
|
| "Do one thing well" allows you to do one thing well,
| tautologically - but it doesn't allow you to do many things
| well. The fact that Unix utilities compose at a very
| superficial level is irrelevant, because the use of text as
| an interchange format is such a heart-stoppingly bad idea
| (consider a programming language where the only type is a
| string - you wanna write a web server in that?) that it
| renders Unix tools near-useless for building larger tools (as
| evidenced by the fact that nothing is made with them), and
| only useful for immediate interactive use, and building small
| scripts with (that would already be better served by a real
| programming language).
|
| The Unix Philosophy is self-contradictory. "Do one thing
| well" is meant to enable composition, for building larger
| programs - but "Text is the universal interface" is in direct
| opposition to building larger programs. But, because tools
| are only supposed to do one thing well, they're feature-
| impoverished and not very useful on their own, so you have to
| compose them. You're screwed either way.
| jmfldn wrote:
| Shell programming through small cli tools was never meant
| to scale into massive complex software so you're comparing
| apples and bananas.
|
| Do one thing well and text as the universal interface works
| well in the small for parsing files, doing sys admin tasks,
| gluing a few things together. That's what it's intended
| for. It's obviously the wrong tool to build a system in.
| Used in the right context they compose beautifully.
| PaulDavisThe1st wrote:
| > Firefox, Linux, gcc, Visual Studio Code, Windows, Chrome,
| Google services, Discord, Spotify, Blender, GIMP, Apache,
| Slack, Office, Steam, Matrix/Element...almost every single
| non-trivial piece of software in existence is not composed
| out of Unix shell utility pipelines.
|
| All true.
|
| However, the development environment (and frequently the
| build systems) used for all of the above are likely
| substantially composed out of Unix shell utilities and
| pipelines, aided by very unix-y tools such as Perl or awk.
|
| That says something, I think. Just not sure what.
| citrin_ru wrote:
| > use of text as an interchange format is such a heart-
| stoppingly bad idea ... consider a programming language
| where the only type is a string
|
| Posix shell is a programming language where the only type
| is a string. Text as an interchange format works reasonably
| well in practice for a wide range of tasks.
|
| To me shell, easy to combine unix commands and text as
| interchange is a clear example of New Jersey style from
| "Worse is better" [1] and their critique comes mostly from
| followers of MIT/Stanford style.
|
| In my carrier I wrote hundreds of small shell scripts which
| use unix commands and text as an an interchange format.
| Yes, I see that some bugs can be prevented/detected by
| using something more strongly typed than shell, but all my
| scripts worked reliably enough and didn't suffer from any
| significant bugs so why bother? (disclaimer: I'm old
| fashioned and like to read man pages; I imagine shell can
| be full of traps if you ignore documentation and use only
| trail and error approach or practice stackoverflow driven
| development).
|
| Of course for large projects and even some small ones other
| tools/languages fit better than shell but shell have its
| niche.
|
| [1] https://en.wikipedia.org/wiki/Worse_is_better
| rustyminnow wrote:
| Different tools serve different purposes. Just because you
| wouldn't write a web browser/server/IDE/OS in a shell
| scripting language doesn't mean they don't have value or
| are failed paradigms.
|
| I've written tons of shell scripts for one-off jobs or
| simple work that would've taken 2, 3, maybe 4 times the
| amount the time to write in a "real" programming language.
| (E.g. throwaway code to generate 10,000 test files that are
| slightly different would take me 5-10 minutes in bash, but
| maybe half an hour in node or python.)
|
| Passing around strings isn't the BEST paradigm but it's
| extremely flexible when you need flexibility. There are
| times when you need something more solid and that's fine
| too.
|
| And fwiw I'd bet a majority of the software you listed uses
| bash somewhere in either their build process or SAAS stack.
| bch wrote:
| > GNU tools are much more widely used on boxes humans
| interact with than BSD/busybox. You don't see everyone trying
| to figure out how to install all of the suckless tools
| immediately after installing linux, etc.
|
| Or perhaps those BSDers, suckless tool users, etc get setup
| and quietly just get to work. I feel that's plausible.
|
| I think you're right re: server/desktop split, which decades
| ago might have been hard to tell apart. Is desktop-computing
| and some loud but ignorant (of Unix) majority directing the
| future of Unix down the garden path or are the
| traditionalists out of touch and just yelling at clouds and
| kids to stay off their lawn?
|
| I fall into the traditionalist camp - I think the Unix that
| got us here is Good and to know it is to love it.
|
| I think pushing back against complexity is (and has been for
| a long time) an additional challenge for BSD/Linux, besides
| it's primary role of being a great compute environment. The
| BSDs have done marvellously here.
|
| > I mean the empirical evidence alone seems point at the Unix
| Philosophy not actually being popular in practice.
|
| I'm worried this is polling 100 people off the street about
| how they care for their kitchen knives and trying to tie that
| back to Michelin Star restaurant kitchens. I don't know...
| wyager wrote:
| Software popularity is almost always a historical accident
| rather than a reflection of users' preferences.
| ReleaseCandidat wrote:
| Almost nobody used the original Unix-tools on any Unix
| (like Irix, Solaris, AIX, HP-UX and Tru64). Everybody
| installed the GNU tools, that's why after some time every
| vendor shipped them with their Unix as add-on disks.
| xxpor wrote:
| Kind of hard to separate cause and effect there. Why does
| my dad prefer Windows? He's used it for 30 years and he's
| used to it. If he switched to Ubuntu, would he prefer that?
| Perhaps, but there's a lot of stuff to learn. So he prefers
| Windows, in some sense.
| traviscj wrote:
| I have the same problem with textmate :-(
| johnisgood wrote:
| I think for a large number of people it would make no
| difference as they are in the browser at all times, or
| the software they use on the daily is available for
| Linux, too.
| the_af wrote:
| > The Unix philosophy of "do one thing well" doesn't actually
| work that well. Dan Luu explains this better than I could.
|
| That quote from the Uncomfortable Truths article is strange
| because Dan Luu doesn't explain that "it doesn't actually work
| well". He just explains that the philosophy is not consistently
| followed, but he is not unhappy with it.
| MisterTea wrote:
| > He just explains that the philosophy is not consistently
| followed, but he is not unhappy with it.
|
| Which is exactly the reason for the glut of command line
| options.
|
| A great example of following Unix philosophy using a more
| recent example is the ssh client on plan 9. It is split into
| three separate programs each with their own man page: ssh(1)
| for terminal access, sshfs(4) for mounting a remote file
| tree, and sshnet(4) which imports a remote machines tcp
| stack. Keep it simple, stupid.
| AceJohnny2 wrote:
| Rob Pike, one of Unix's co-creators, and owner of quite a sharp
| tongue, put it best in a Slashdot interview:
|
| _" Those days [of the Unix Philosophy] are dead and gone, and
| the eulogy was delivered by Perl."_
|
| https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
| fsckboy wrote:
| ok sure, but unix is still here and perl died
|
| there's a subtle thing about perl that's not mentioned often,
| which is how it borrowed ideas from many other tools and that
| made perl "intuitive" to learn for people who knew the other
| tools. But once you're embedded in just perl for awhile, you
| forget the other tools and then perl's grab-bag of borrowed
| ideas becomes sort of burdensome, it loses "intuitiveness".
| avgcorrection wrote:
| Usually both the Unix Philosophy gets uncritical praise _and_
| many people complain about how unstructured shell application
| data is. The great thing about this essay is that it connects
| the two dots and finally concludes that "do one thing well" and
| "text is the universal interface" go together like oil and
| water.
| BrazzVuvuzela wrote:
| In years past, some Unix utilities used to do things like
| silently truncating long lines that were too long for the
| static buffers used by those tools. The GNU Coding Standards
| document (originally written in the early 90s I believe)
| specifically says not to do things like this (GNU's Not Unix,
| after all..)
|
| > _For example, Unix programs often have static tables or
| fixed-size strings, which make for arbitrary limits; use
| dynamic allocation instead._
|
| > _Avoid arbitrary limits on the length or number of any data
| structure, including file names, lines, files, and symbols, by
| allocating all data structures dynamically. In most Unix
| utilities, "long lines are silently truncated". This is not
| acceptable in a GNU utility._
|
| https://www.gnu.org/prep/standards/standards.html
| ReleaseCandidat wrote:
| The 'Unix Haters Book' has some too:
|
| https://web.mit.edu/~simsong/www/ugh.pdf
| marcodiego wrote:
| The UHHB has very few points that are still valid. It is a
| humorous piece and was written about 3 decades ago. We
| shouldn't continue citing it as valid criticism.
| ReleaseCandidat wrote:
| > The UHHB has very few points that are still valid.
|
| I disagree. Yes, nobody uses sendmail anymore, filesystems
| vastly improved and X isn't a resource hog any more. I've
| reread it some months ago and the main points still hold.
|
| For example the part about `kill`: Most
| operating systems have a "kill" command. So does Unix. In
| most operating systems, the kill command kills a process.
| The Unix implementation is much more general: the
| "kill" command sends a process a message. This
| illustrates the first Unix design principle: * Give
| the user power by making operations fully general.
| The kill command is very powerful; it lets you send all
| sorts of messages to processes. For example, one
| message you can send to a process tells it to kill
| itself. This message is -9. -9 is, of course, the
| largest single-digit message, which illustrates another
| important Unix design principle: * Choose
| simple names that reflect function.
| monroeclinton wrote:
| I don't find the argument about kill convincing. You can
| use `kill pid` and it will send a SIGTERM signal to the
| process. The -9 option is only necessary when you want to
| send a SIGKILL signal. I don't think it is a bad thing
| that kill gives users the option to choose which signal
| to send. I only use the -9 option when I want to
| terminate a process without it being handled.
| Athas wrote:
| While I agree that there's much of the UHHB that is still
| valid (and what's not valid is still funny), I don't
| think that's a good example. Modern kill allows you to
| provide the signal name if you wish. I don't think it's a
| particularly good criticism of kill that it also allows
| you to use a numeric shorthand if you wish (even if that
| shorthand is very popular).
|
| I think the UUHB is mostly worth reading to understand
| the absolutely _dismal_ state of proprietary Unix in the
| 90s. It explains why technical reasons contributed to the
| growth of both Windows NT and GNU.
| tra3 wrote:
| Interesting article, but I don't see how the increase in number
| of arguments invalidates the "do one thing well".
|
| Sure ls has a 58 (!) arguments but it's still a tool to list
| files ultimately.
|
| > I've heard people say that there isn't really any alternative
| to this kind of complexity for command line tools, but people who
| say that have never really tried the alternative, something like
| PowerShell.
|
| I've spent a lot of time passing around JSON and XML, not the
| same but similar. While it's true that structured data makes
| things easier, it's not without it's own faults.
|
| I subscribe to unix philosophy of "do one thing well" and pass
| text around because it's served me well. You have to question
| status quo to come up with something new and better, but so far
| I'm not seeing it.
| useerup wrote:
| > Sure ls has a 58 (!) arguments but it's still a tool to list
| files ultimately.
|
| No, it has evolved into a tool to get files/directories of a
| directory _and_ sort them _and_ format them.
|
| Powershell separates those. `ls` in Powershell gets filesystem
| objects. It does not have any of the nix craziness for
| controlling the output and sorting, yet it is possible to do
| the exact same thing by piping output from ls into a format-
| command like format-table(ft), format-list(fl) or even
| convertto-json
| AtlasBarfed wrote:
| AND YET LS STILL IS NOT RELIABLY PARSEABLE
|
| And yet there aren't --json (and/or --yaml) universal output
| option flags to structure your data in a reliably parseable
| format.
|
| Shouldn't every option for a major UNIX command (insert your
| definition for major) have an extensive list of useful
| examples/use cases? Man still fails me here. As does the AWS CLI
| too as a side complaint. If your option is important and useful,
| then it demands a good example.
| shatteredgate wrote:
| It doesn't really make sense to have unix commands output json
| or yaml. They're already doing a form of parsing internally,
| you're then asking them to encode the output in another text
| format so you can parse it again. Why? You'd have better
| results just using the underlying API to get a list of files,
| and this is what every other program that needs to get a list
| of files actually does. From a scripting perspective this is
| one of the things that powershell actually got right.
| AtlasBarfed wrote:
| well, because, ls, lsblk, ps, and a host of other table-based
| outputs aren't reliably parseable. Their columns overflow.
| They aren't durable to line breaks in indentifiers and other
| UTF8 and control character oddities.
|
| You know what is? A decent data output format. And JSON is
| the best of the compromises that exist now. YAML would be
| nice because if you are outputting json, yaml output is easy
| and it's a bit more readable.
|
| That doesn't violate the UNIX philosophy of text output. It
| probably improves it.
|
| Underlying APIs aren't as universal, portable, or well-known.
| We are talking basically GNU cross-platform programs.
| shatteredgate wrote:
| But you don't actually want to parse them though, that's
| the mechanism by which you receive the data but the real
| end goal is you just want the data in its canonical format
| so it can used programmatically; in powershell there is no
| parsing, the output _is_ always the canonical
| representation.
|
| I don't get what you meant in the last sentence, the
| underlying API is glibc which is also cross platform and is
| incredibly well known. Other cross-platform languages like
| Java, Golang, Rust, etc have their own portable APIs to
| enumerate directories that are cross platform.
| munk-a wrote:
| I read in an article (this one - joke) that all lower case
| letters except `jvyz` are in use - it looks like `-j` and `-y`
| are just sitting there waiting for someone to add some output
| formats - then we just need to add a verbose flag and... maybe
| a switch that automatically gzips the output? We're so close to
| the 100% completion achievement - we can get there in our
| lifetimes.
| justinsaccount wrote:
| Something like https://github.com/Juniper/libxo is probably the
| best bet for non-powershell, non-python like things to ever be
| properly parseable.
| dang wrote:
| Discussed at the time (of the article):
|
| _The growth of command-line options, 1979-Present_ -
| https://news.ycombinator.com/item?id=22473821 - March 2020 (171
| comments)
| mjw1007 wrote:
| A gentle suggestion for bloggers: if you're going to write an
| article with a title like "The growth of command line options,
| 1979-Present", please also arrange to prominently display the
| date of composition.
| ghaff wrote:
| Really, any blog post should have a prominent date on it. For a
| lot of things, it's essential context. Older posts _can_ be
| useful /interesting but they can also be pretty much completely
| useless depending upon the topic.
| bo1024 wrote:
| Every article (really, every thing) posted on the web should be
| timestamped.
| pugworthy wrote:
| March 2020 for those of you who just had to find out after
| reading this comment.
| HotHotLava wrote:
| > The latest year in the table is 2017 because I wrote the
| first draft for this post in 2017 and didn't get around to
| cleaning it up until 2020.
___________________________________________________________________
(page generated 2021-12-15 23:00 UTC)