17 ms·
The growth of command-line options, 1979-Present
- Anointmous 7y agoWhat we really need is a feely user interface. This would consist of users blindly groping in the dark for the thing they need.
- dexen 7y agoUNIX Style, or cat -v Considered Harmful, http://harmful.cat-v.org/cat-v/ http://harmful.cat-v.org/cat-v/ (see the linked PDF, http://harmful.cat-v.org/cat-v/unix_prog_design.pdf http://harmful.cat-v.org/cat-v/unix_prog_design.pdf) Another example: the modern Bash shell vs the Plan 9's Rc shell. The difference in documentation is over tenfold, with the latter still being more less laden with gotchas: $ man bash | wc -w 48189 $ 9 man rc | wc -w 3264 Having said that, I still love me some sick diff -burN-style mnemonics.
- MichaelMoser123 7y agobut rc doesn't have built in regex and doesn't have hash tables. My guess is that bash is trying to be a full scripting language these days, sort of like perl.
- MisterTea 7y agoBecause rc is a shell to run commands, hence the name rc, run command. For the tasks you mentioned you would use a program or language such as awk to handle those cases.
- dexen 7y ago>but rc doesn't have built in regex and doesn't have hash tables That's an advantage; Plan 9 provides awk for those use cases. There is a clear separation, and a simple yet powerful language for communication (pipes, file descriptors, and files). >bash is trying to be a full scripting language these days Arguably Bash over-did somewhere around the time they added support for TCP connections exec {FD}<>/dev/tcp/news.ycombinator.com/80; echo GET / >&$FD; cat <&$FD
- cat199 7y agoNot sure if arguing for plan9 simplicity by pointing out bashisms designed to emulate how one might use sockets on plan9/rc is the best strategy.
- AnIdiotOnTheNet 7y agoThe difference being that such functionality arose from the fundamentals of how plan9 worked, whereas bash hacked in a simulacrum.
- nimrody 7y agoActually, that's something that seems inspired by Plan 9 with its /net/tcp/xxx files. Bash just tries to make it cross platform so it cannot rely on the host OS like rc does.
- mprovost 7y agoThere were already netcat and similar tools that worked together with bash to provide this functionality.
- chubot 7y agoMaybe there was a clear separation 30 years ago, but there no longer is. The shortcut for the posts below is that you can write a Lisp in all of shell, awk, and make (and sed too) [1] I won't get to this in Oil (without help) but I still think it's valid. The languages have so much overlap that they should just be combined. Of course that's what Perl was (leaving out Make), but Raku and Python 3 seem to have left a hole in that design space. Shell, Awk, and Make Should Be Combined http://www.oilshell.org/blog/2016/11/13.html http://www.oilshell.org/blog/2016/11/13.html Example Code in Shell, Awk, and Make http://www.oilshell.org/blog/2016/11/14.html http://www.oilshell.org/blog/2016/11/14.html [1] https://github.com/kanaka/mal/tree/master/impls https://github.com/kanaka/mal/tree/master/impls
- m4r35n357 7y ago$ man dash | wc -w 10122 If you are running scripts most of the time bash is overkill (batch files don't need things like command completion, history and all that interactive stuff). Don't believe me? $ ls -lAh `which bash` -rwxr-xr-x 1 root root 1.1M Jun 6 2019 /bin/bash $ ls -lAh `which dash` -rwxr-xr-x 1 root root 119K Jan 25 2018 /bin/dash
- MisterTea 7y agoThe entirety of plan 9 cat is just 36 lines. That's true unix philosophy. Small tools that do one thing well which when combined produce more powerful tools. The -v flag is silly bloat as cat is nothing more than a program which catenates files.
- cmurphycode 7y agoThanks for the new addition to my mnemonic collection! perl -lane # process input by line, split into fields, print outputs with new lines, execute code netstat -planet # show process, extended info, all socket types ss -pimento # basically every piece of info about live connections iostat -txyz # extended, omit first report (the since-boot one), omit devices with no activity, log datetime
- dexen 7y agoImagine an old PS/2 mouse with a mini Jack cord & plug. Non-standard but works. I mean, on GNU/Linux: ps aux Party time: rsync -rave ssh SOURCE DESTINATION
- Izkata 7y agoless -SEXIER Truncate long lines instead of wrap, quit at eof, don't clear the screen, show ansi color escape codes as colors but escape other ansi escape codes. (The second E does nothing but complete the word)
- kstenerud 7y agoThis is another reason why I'm developing an ad-hoc data representation with strong typing. JSON was almost right, but failed because there are too many fundamental data types that cannot be represented in a portable way. A general purpose ad-hoc data format with all the fundamental types, that doesn't require endless text parsing but can be converted to a 1:1 text format for human viewing, would be helpful in so many situations, including serialization for piping between unix tools. https://github.com/kstenerud/concise-encoding#example https://github.com/kstenerud/concise-encoding#example
- pinkfoot 7y agoASN.1 ?
- throwaway3157 7y agoCool. When you evaluated all the alternatives, did you stash a pro/con list somewhere on a blog? I’d appreciate reading it
- hwbehrens 7y agoThere is a comparison table on the linked GitHub page, with the following formats: Concise (the proposed format), XML, JSON, BSON, CBOR, Messagepack, Cap'n, Protobufs, Flatbuffers, Thrift, and ASN.1. Although not technically a pro/con list, it highlights the evaluation criteria used to compare.
- tclancy 7y agoI am with the author on the general point. But I think it ignores the fact discussing how things were in the '60s when the commands were written just for people ignores a fundamental change. To wit: >the added options are convenience flags: setting the permissions of the new directory and making parent directories if they don't exist. Obviously completely unnecessary for normal users, but those have to exist for automated processes. The "problem" is caused in part by the success of Unix, that now computers are using computers.
- oefrha 7y agoIf you believe mkdir -p is completely unnecessary for normal users and only exists for scripting, you probably want to think about how it might fit into your workflow again. In fact, my mkdir is simply aliased to mkdir -p, and I have a self evidently-named wrapper function called mkcd which I use even more often than mkdir.
- AnIdiotOnTheNet 7y agoSince one can alias commands to functions, that does suggest that in fact mkdir -p is actually unnecessary.
- tclancy 7y agoI immediately second-guessed my use of "Obviously completely"-- what I meant was "We can get by without it" whereas a standalone script cannot.
- rb808 7y agoI think its just a reflection of how much more widely software is used, how complicated our environments are, how many admins/developers there are compared to the old days. Eg the aws command is hugely complicated, but I'm not sure breaking it out into smaller commands easily really would make anything easier, just pollute the command line namespace.
- lotwxyz 7y agoIn my web-based shell implementation [0], I use a library concept, such that you have to "import" commands into the current execution environment. You can either do this kind of thing: $ import fs This imports all the commands in the 'fs' library, without any concern for namespaces, and if there are any already existing commands with the same name, they are not overwritten (the new ones are not imported). But if you do this: $ import fs as myfs Then, all the commands in the 'fs' library are invoked like this: $ myfs.vim [0] https://dev.lotw.xyz/shell.os https://dev.lotw.xyz/shell.os
- mjcohen 7y agoAre you notified of the ones that are not imported?
- IHLayman 7y agoIsn't it possible that, like human languages that evolve over time for multiple reasons (https://en.wikipedia.org/wiki/Language_change https://en.wikipedia.org/wiki/Language_change) such as language contact, principle of least action, and pejoration, that computer languages also experience similar shifts? All of this grumbling about how command line options have exploded or why doesn't everyone use language X or shell Y or OS Z that has existed for forever is similar in tone to me about people who grumble about Oxford commas or starting sentences with conjunctions or (heaven forbid) using emojis? Of course some principles of speech and syntax should stay around (as they probably exist for a good reason), but it is foolhardy to grip tightly onto any language, human or computer, thinking it will always stay the same, when it plainly won't.
- beigeoak 7y agoI'm assuming you didn't read the article, because a lot of the author's examples have nothing to do with evolution or complexity. Also please don't compare human languages to programming languages to make a point. It's the programmer equivalent of bad managers comparing Java to JavaScript. Argument by analogy in such situations is a sign of not having a basic understanding of the problem at hand. Yes I am aware of the contradiction.
- dexen 7y agocomputer languages also experience similar shifts? Partly, but less so. Human language vocabularies approximate Huffman Coding - the more frequently used words (and phrases) tend to be proportionally shorter. This is a gradual process for spoken languages, and somewhat quantized for written languages.[1] It's possible because with human languages, "close" is "good enough"; one can read english written with ye olde orthography, if with a bit of extra effort. Less so in the lifespans of particular programming languages. Per Postel's law we tend to be liberal with extending but conservative with breaking backward compatibility. I think the case of command line tool parameters is particularly conservative for various reasons; among them because the 'knowledge' of options is spread among multitude of separate project - many of them obscure and bespoke - and coordination would be nigh impossible. However there are some signs of similar trends; note how the "function" and "integer" and similar keywords of older languages tend to turn into "fn" and "int" in newer languages. -- [1] Not sure if there's a comparable process for grammars, but I guess it's a fair bet...?
- OskarS 7y agoThis bums me out as well. One of the prime examples of this is tar: whenever someone says "extract this tarball", they usually give the command as this: tar xfvz my-source-code.1.2.3.tar.gz What does those flags mean? Who knows! I mean, I know because I've used it enough, but for many people those are just a mysterious incantation (there's even an xkcd about it! [0]) The reason is arguably that tar has too many responsibilities here. Tar should only do two things: create tar streams and extract tar streams into files. You do that with "tar c" and "tar x", and that's everything you should need to remember (ok, fine, "tar t" for listing files is good to know as well). Commands to create tarballs should look like this: tar c directory | gzip > directory.tar.gz And untar commands should look like this: zcat directory.tar.gz | tar x or maybe cat directory.tar.gz | gunzip | tar x or whatever version you prefer with "tar x" at the end. This is composable, super-easy to remember, and you can VERY easily swap out any parts for any other parts (for instance, changing the source from a file to a url with curl, or the destination for an ssh pipe or something). One of the benefits of the "swapping out" parts are of course that you're not restricted to what's built into tar: you can use ANY compression utility you want. For instance, there's a thing called pigz[1] which parallelizes gzip decompression for increased speed. It's trivial to swap into the pipeline when you use tar that way: cat directory.tar.gz | unpigz | tar x Congratulations, you now have much faster expansion of tarballs, without needing to recompile tar. We've taught a generation of programmers that "tar" is hard to use and you have to look up a magic incantation every time you need it. Ironically, that makes tar less flexible, because now you think of it as a single-purpose utility (creating and unpacking compressed tarballs) instead of a versatile unix tool which can be used in all sorts of different situations. [0]: https://xkcd.com/1168/ https://xkcd.com/1168/ [1]: https://zlib.net/pigz/ https://zlib.net/pigz/
- kanox 7y ago> tar xfvz my-source-code.1.2.3.tar.gz Modern tar can detect the format so "tar xfv" is enough. The "v" option only means "verbose" so it's better just "tar xf" and avoid spamming the terminal.
- jandrese 7y agoI always use -v because every so often I find a tarball that was taken from inside of the working directory instead of outside. Of course these days it's not humanly possible to ctrl-c it before it extracts thousands of files and makes cleanup a chore but at least you won't be confused as to what happened when you attempt to cd into the directory later. For that matter knowing what directory to cd into is also a good reason to use -v. Note: If none of your files were clobbered and there are no spaces in the filenames to worry about you can do: tar -tf [tarball] | xargs rm -d Run it repeatedly if you also want to remove the directories.
- lancyH 7y agoThis problem is universal. The solution is to use --words instead of -s single letter options. Thankfully, git has a good manual that covers all the options: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- dmitrybrant 7y agoffmpeg says, "hold my beer"! https://ffmpeg.org/ffmpeg.html https://ffmpeg.org/ffmpeg.html
- dylan604 7y agothat was confusing. when i read this, it was exiftool, so i was going to reply with ffmpeg. looks like you felt it was a better example as well anything as powerful as FFMPEG, EXIFTool, ImageMagick, x264/265, etc is going to have switches/options from hell just out of plain necessity. these are not simple little Unix-esque tools. these are full blown applications that just happen to not have a UI.
- kqr 7y agoThe same thing goes for ImageMagick, but that seems unfair because it's more that they have created a command-line language for describing multimedia transformation pipelines. It's not as much that the arguments allow you to run a program under variant configurations, but rather that you create completely new programs for each run.
- _Gyan_ 7y agoYou've missed all the component options :) See https://ffmpeg.org/ffmpeg-all.html https://ffmpeg.org/ffmpeg-all.html
- jandrese 7y agoI'll note that video encoding GUI screens tend to be overwhelming as well. It's simply a complex problem with a whole lot of parameters you might want to tweak. The alternative is to hide all of the complexity and hope that the defaults are good enough for your users. Which works ok for stuff like Mom encoding her cell phone video but falls down pretty quick when someone needs to do something slightly out of the box, like add in a second audio track.
- djsumdog 7y agoFor the later years, it would be interesting to see the comparison for GNU fileutils vs what's in the base of FreeBSD or OpenBSD vs what's offered by busybox. The author mentions this briefly with Darwin's ls command (which looks like it might just come directly from another BSD). Also tar's increases might include new compressions methods like bzip2, XZ, etc.
- mprovost 7y agoRight, but what business does tar have compressing anything in the first place? It's a tape archiver. You can pipe its input/output to compress or gzip or bzip2. Early versions didn't have any ability to compress/decompress archives and relied on external tools, but then that functionality was absorbed, increasing the size of the codebase. And as you point out, every time a new compression method is invented, someone needs to update a bunch of tools instead of just installing one new utility.
- dylan604 7y ago> but what business does tar have compressing anything in the first place? It's a tape archiver. Most of the tape devices themselves had/have compression on them so that tar did not need to do it. However, that compression was pretty weak (2:1), so giving tar the ability to use bzip2 and send the compressed data stream to the tape (bypassing the hardware compression) gave the user much more convenience. Also, older systems probably were bad at doing the compression in real-time, so it probably slowed down the write to tape. I'm just guessing, I have no experience writing to tape from such an old system. I'm not really upset by tar geting some extra features.
- int_19h 7y agoIs compression support in tar built-in? I always thought that those switches simply use gunzip etc under the hood.
- pcj-github 7y agoSeems like a natural progression given the growth in usage of these tools over the last few decades. How many people were using these tools in 1979 compared to today?
- seemslegit 7y agoCommand line options are a terrible surface for usability and more importantly, discoverability. We are at least two decades overdue for replacing them with a structured, typed, reflective API and yet every generation of hackers persists to cargo-cult the cli utility, taking pride in remembering copious minutia as if they were wizzards in command of arcane incantations.
- agsilvio 7y agoWhile I can't disagree, we should recognise that this was appealing to early computer scientists.
- seemslegit 7y agoWe very much do, at least in their hats as hackers (true computer scientists never cared much about actually using computers) there was a point where an online command prompt (one you could edit in real time, as opposed to having to put in a new punch card etc.) was state of the art of interactivity and software interoperability was defined on the level of word sizes and hardware registers, but we can and should move on from that.
- fctorial 7y agoHow do you feel about argv?
- seemslegit 7y agoWhat about argv ?
- fctorial 7y agoArgv in 'int main(int argc, char argv)'. CLI is a wrapper for this.
- seemslegit 7y agoWhat exactly does it "wrap", splitting a single string into an array of strings ?
- 6gvONxR4sf7o 7y agoTo some degree it reminds me of a change in Haskell that came about a few years back. It used to be the case that many of the basic functions operated on things like lists and functions. Tricky to learn but not too bad. It got annoying when you wanted to use those tools on generalizations of lists, so the language changed. Now those standard library functions operate on things like the Foldable type class which is must follow some laws defined in terms of endomorphisms. So simple functions like “any” or “concat” which used to operate on lists and be super newbie friendly still can operate on lists in the same way, but now do lots more, at the expense of the newbies (and complexity). I think the change was jokingly called “pulling up the ladder behind us.” Learning some command line commands feels like learning a whole new framework. A man page should rarely need to be a whole damned manual.
- geofft 7y agoThey still work on plain lists with the same syntax you could always use (that is, lists are a member of the Foldable type class), right? If so, then this primarily seems like an issue of how to present the documentation and not the mechanics of the change itself. Instead of autogenerating docs that say concat :: Foldable t => t (t a) -> t a (or whatever) and making people think about Foldable, write docs that say that concat is still [[a]] -> [a], with a note at the bottom saying, by the way, this generalization exists, click here to see the more complicated version if you've decided you care about Foldable. Probably the text of the docs remains the same, in fact ("concatenate a list of lists together into a single list"), you just display the real prototype and explain that "list" could also mean something else. (There's a number of ways to implement this, from writing docs by hand, to extending the doc protocol to support this specific case of lists and Foldable, to extending the doc protocol to support documenting a fake function prototype and then have a link to the real function at the bottom, and using the type system to ensure that the fake prototype is just a special case of the real function.) A corollary is that documentation presentation is an inseparable part of library / tool design.
- kqr 7y agoThe other problem are type errors, which would then require knowing about Foldable to operate on lists. The same type of solution that you propose for docs can work here too, though. The compiler can trivially substitute the typeclass for any known instance.
- mkchoi212 7y agoIt seems like businesses are pushing towards releasing command line tools to make their business "hacker friendly." One example I can think of is Github and their new GitHub CLI.https://github.com/cli/cli https://github.com/cli/cli
- mosaic-io 7y agoSuper fan of the new Github CLI.
- lalaithion 7y agoI feel this way about optional function parameters. They have a tendency to proliferate, because you don't break existing code by adding them, and they're always optional.... until you have https://scikit-learn.org/stable/modules/generated/sklearn.svm.SVC.html#sklearn.svm.SVC https://scikit-learn.org/stable/modules/generated/sklearn.sv..., where you have 15 optional parameters.
- dgritsko 7y agoRelevant XKCD: https://xkcd.com/1168/ https://xkcd.com/1168/
- chubot 7y agoThe way I remember tar syntax is to use it more like a "normal" command. That is, instead of the convenient but cryptic idiom: tar xvf foo.tar.gz # extract, verbose, file I use the longer but more readable stream idiom: tar -x -z < foo.tar.gz tar --verbose -x --xz < foo.tar.xz (It does force you to specify -z for gzip or --xz for .xz, but I'm OK with that redundancy in the name of readability.) This makes it easier to remember the syntax for create and list too: $ tar --create e.txt k.txt > out.tar $ tar --list < out.tar e.txt k.txt That's how I write the install instructions for Oil: https://www.oilshell.org/release/0.8.pre2/doc/INSTALL.html https://www.oilshell.org/release/0.8.pre2/doc/INSTALL.html ----- So basically tar can behave normally (at least GNU tar can) -- it's just that there's an ancient idiom that most people have in their fingers, and that's copied around in various instructions. The nice thing about the verbose way is that the hyphen prefix enables autocomplete.
- jcelerier 7y agoI prefer my mnemonics : tar caf foo.tar.gz foo/ bar/ # Compress As Fuck tar xaf foo.tar.gz # Xtract As Fuck
- blt 7y agoNone of those SVM parameters stick out as obviously unnecessary to me. What alternative do you propose for functions that have many minor variants with a large common core, and many hyperparameters?
- choward 7y ago> that's the beauty of command line options -- unlike with a GUI, adding these options doesn't clutter up the interface GUIs provide discoverability so often times you don't need a manual. If you don't know how to use a command line tool you must open the manual. So in that way I would consider the man pages as part of the UI and those definitely get cluttered.
- socialdemocrat 7y agoThe discoverability of a GUI deteriorated as you add more options.
- K0SM0S 7y agoI've worked with music software GUIs, these are notoriously plagued by feature-creep. For a desktop paradigm, there is always a way to do better with GUI as you add more features; but you'll refactor / redesign a lot on the way and that has a cost in familiarity, which directly impacts user productivity. It's a trade off. The dirty secret of discoverability is that only a tiny subset of features is relevant at any time in the UX, and identifying that subset + triggering user awareness about it is the "art" part. We learned a lot with mobile in that regard because the harsh limit on real estate becomes incentive to identify the essentials. Discoverability doesn't have to suffer from complexity of the software, but it's not just UI design, it's UX.
- perl4ever 7y ago"The dirty secret of discoverability is that only a tiny subset of features is relevant at any time in the UX" For some reason, designers and some users don't like it, but a hierarchy (folders, menus, etc) is something many people find useful and effective. But it seems pretty common to declare people can only handle a few options plus search.
- randoramax 7y agoAnd search, something that Ubuntu HUD/Unity (now on the extinction path) solved in a very elegant way. Hundred of menu options nested in remote menu folders made available by typing names. Best of both worlds, if you ask me.
- socialdemocrat 7y agoHmmm... maybe there is an opportunity here in replacing all the Unix tools with simple versions. I personally don’t use most of these options and their existence just clutter up the manual.
- samatman 7y agoOn balance, I prefer this. Extra command flags neither pick my pocket nor break my leg. The alternative (presuming the extra functionality is useful to someone, somewhere) would seem to be more standard commands, and that choice would use up more of the precious global namespace for small yet memorable lower-case command names. I prefer as much of that as possible be reserved for userspace. I'll admit my mind boggles a bit when I ask myself what tar could possibly do with 139 flags, and it makes me a bit nervous about the surface area the program exposes.
- p1mrx 7y agoIt's strange that ls has grown to 58 options, but still can't output \0-terminated filenames: https://unix.stackexchange.com/questions/112125/is-there-a-reason-why-ls-does-not-have-a-zero-or-0-option https://unix.stackexchange.com/questions/112125/is-there-a-r... As an exercise, try to sort a directory by size or date, and pass the result to xargs, while supporting any valid filename. I eventually just gave up and made my script ignore any filenames containing \n.
- whelming_wave 7y agoHere you go: sort all files in the current directory by modification time, whitespace-in-filenames-safe. The `printf (od -> sed)' construction converts back out of null-separated characters into newline-separated, though feel free to replace that with anything accepting null-separated input. Granted, `sort --zero-terminated' is a GNU extension and kinda cheating, but it's even available on macOS so it's probably fine. printf '%b' $( find . -maxdepth 1 -exec sh -c ' printf '\''%s %s\0'\'' "$(stat -f '\''%m'\'' "$1")" "$1" ' sh {} \; | \ sort --zero-terminated | \ od -v -b | \ sed 's/^[^ ]*// s/ *$// s/ */ \\/g s/\\000/\\012/g') If you're running this under zsh, you'll need to prefix it with `command' to use the system executable: zsh's builtin printf doesn't support printing octal escape codes for normally printable characters, and you may have to assign the output to a variable and explicitly word-split it. This is all POSIX as far as I know, except for the sort.
- ailideex 7y agoAnother alternative find /etc/ -mindepth 1 -maxdepth 1 -type f \ -printf '%s:%T@:%p\000' \ | sort -z -t: -k1,1g \ | sed -E -z 's/^[0-9]+:[0-9.]+://g' \ | tr '\000' '\n' Sorts by size, can just change -k1,1 to -k2,2 to sort by date. Tested on fedora 31 with gnu find, sed, sort and tr. And really the answer given at the stackexchange link is quite on point: > However ls is really a tool for direct consumption by a human, and in that case further processing is less useful. For futher processing, find(1) is more suited. Find is the right solution, find gives you an enormous amount of control, to re-implement find in ls seems counter productive.
- loeg 7y agoBy size: python -c 'import os; \ os.write(1, b"\0".join( \ sorted(os.listdir(b"."), key=lambda p: os.stat(p).st_size)))' \ | xargs -0 ... By date: swap st_size for st_mtime. (Python3 does try to make this hard on us — Unix path names are just bags of bytes, but Python insists that printing must have some known encoding. I get around that by abusing os.write(1, ...) and by adding the dummy b"." argument to os.listdir(), which forces the results to be in bytes format.)
- jokit 7y agoI have wondered how it is that my Mac Plus became a machine with almost no noticeable delays when I upgraded to 4mb ram, and now I have 8gb of ram, and a less responsive system. I realize my system is far more dynamic today. I just wonder if one day we'll be using systems with 4tb of ram that would be snappier if upgraded to 8tb or 16tb. Given the nature of open source, I'd be surprised if there isn't a alternative for less dynamic, less resource req, systems. Is there a system out there that still uses fewer commands? I don't know how to ask this next question, so please bare with me.. Are there any modern systems that don't require modern hardware, but are just more efficient versions of past systems? I have been happy with the way I could use my computer for the last 20 years (probably earlier, too).. so are there any efforts to keep the simplicity of older systems that were adequate for most, make them more efficient, and either have "super hardware", or I suppose very cheap hardware? Thanks for anyone who made it through my ignorant ramblings.
- bear8642 7y ago>I just wonder if one day we'll be using systems with 4tb of ram that would be snappier if upgraded to 8tb or 16tb. Can't find but feel there's a quote like "Programs will grow to fill memory"
- jokit 7y agoI know that some people are only as efficient as they're forced to be. I hope there are efforts to take what is needed, and make it more efficient. There are efforts like Commander X16 to make a new 8 bit computer, and others where people are rewriting things in Rust.. BTW, I have a first gen iPad sitting around that worked very the first two years or so of its existence, and it barely functions today. I know part of that is Apple "protecting" older batteries by slowing down older stuff so we go out and buy new things, but I would like to believe that we're capable or creating an OS for that hardware today that would run better than it did originally, rather than barely function at all.
- zeckalpha 7y agoNot necessarily on the desktop today, but yes. There are workloads like this out there.
- anonymousiam 7y agoThe only command on the list (from 1996, not 1979) that still has no arguments is 'clear'. Back before clear, I used 'echo ^V<esc>c', but that's not portable to different termcap/curses/ncurses display devices.
- souprock 7y agoOuch, the /usr/bin/tar team beat me. I only added 63 options to /bin/ps from Slackware 3.1 (1996) to Ubuntu 12 (2015). They added 81 options. If I'd known about the contest, I could have added enough options to win. The true winner is probably gcc though, which was unfairly excluded from competition. Over 1000 options is excellent work.
- carterehsmith 7y agoIs there a better way? Can we make gcc with less options, while still catering to all the use cases.
- Paul-ish 7y agoThat might not be possible. What if instead we created a configuration tool that intelligently passed the correct options for you.
- carterehsmith 7y agoCould that tool magically reduce the number of options? That would be quite a tool.
- bentcorner 7y agoYou could subdivide what gcc does into other utilities each with a smaller api.
- TeMPOraL 7y agoThis way lies Node.js. You'll end up with a complex config file just to orchestrate all these smaller utilities.
- Paul-ish 7y agoYes. We will call it autotools.
- 7y ago
- ggm 7y agoa plague on getopt, and especially gnu getopt. that said, I live in it.
- hyperion2010 7y agoAnecdote from yesterday. Me staring at merge-pathnames and wondering why everything was backwards from the physical layout of the paths. Ah, it is because the default is optional because of the direction in which the function is usually used. If I didn't take the 5 minutes to wonder about what I was missing I would have implemented a macro to do it the way I thought was most sensible. In the context of the op, I can only imagine that the impulse to pause and reflect on the question of why, or what motivates the desired for a new option has fallen victim to the fact that there are thousands of people for whom the flag solves a real and tangible problem immediately.
- pixelbeat__ 7y agoGNU coreutils has been very careful when adding new options. We're also careful to provide constructive feedback on why it might be best _not_ to add an option, and have summarized many of these discussions https://www.gnu.org/software/coreutils/rejected_requests.html https://www.gnu.org/software/coreutils/rejected_requests.htm...