| |||||||||||||
30 years of GNU30 years of GNUPosted Sep 27, 2013 12:37 UTC (Fri) by nix (subscriber, #2304)Parent article: 30 years of GNU
Some of the things we didn't get turned out not to be terribly important. File version numbers, for instance, are far inferior to a proper version control system: most people I know who used VMS just found 'real' version numbers annoying, and cleaning them up a tiresome chore. Far better to have tree-wide versioning as and when you need it (and with btrfs we gain something vaguely similar, in the form of cheap snapshots that actually work, for any arbitrary subtree). Terminal-independent display support we had already, didn't we? (I presume by that he meant something more like curses than X).
The Lisp-based windowing system would have been really cool. Instead we got X, and then Wayland, and any sign of the dynamic programmability Sun had with NeWS back in the day has just disappeared: Lisp-based window managers really are not of the same order. :/ No Lisp as a system programming language, except if you consider Emacs a critical part of your operating system like I do. The ultimate goal -- a free Lisp Machine, with all its dynamic control and ability to rewrite anything instantly -- is still as distant as ever.
I find it curious that he considered filename completion harder than a Lisp-based windowing system. Perhaps it's just that it needed more storage to implement well?
(Log in to post comments)
30 years of GNU Posted Sep 27, 2013 12:47 UTC (Fri) by hummassa (subscriber, #307) [Link]
Filename completion isn't hard per se, but "completion" is... have you read the files under /etc/bash_completion.d ??
30 years of GNU Posted Sep 28, 2013 23:37 UTC (Sat) by marcH (subscriber, #57642) [Link]
bash_completion.d is always one of first thing I disable, reverting to the good old, pure "directory" completion.
This idea that the shell can predict every single verb+object combination I type is completely ridiculous and infuriating because always missing corner cases.
Also note nothing too complex ever works really reliably.
30 years of GNU Posted Sep 29, 2013 0:00 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
> Also note nothing too complex ever works really reliably.
Indeed, bash "completion" plugins are terrible and have caused me a lot of techsupport woe. It fails just often enough to make life miserable... e.g. people thinking that a file doesn't exist because it just won't complete.
Ideally computers should do the right thing. But when they can't do the right thing they should do the explicable thing. In our quest to make computers right more often we've added complexity that increases inexplicable exponentially when they don't get it right.
It's not always a good tradeoff.
30 years of GNU Posted Sep 29, 2013 17:24 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link] e.g. people thinking that a file doesn't exist because it just won't complete. That one drives me nuts, personally. For example, suppose I download a compressed tarball, not noticing if it's foo.tar.gz, foo.tar.bz2, or foo.tar.xz. If I type tar zxvf foo[TAB], the over-fancy completion rules won't complete the filename unless it's actually a tar.gz. I'd rather it expand the filename, so I can then go back and edit the flag I gave to tar based on what I see in the completion, but the completion scripts take the flags I've given tar already a bit too seriously.
30 years of GNU Posted Sep 29, 2013 17:52 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
The use of specific flags based on the format is entirely redundant for a long time and I am not sure why you bother to do that anymore. Tar does do the right thing automatically here.
30 years of GNU Posted Sep 29, 2013 18:20 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link]
I missed the memo on that. It appears a my webserver is old enough to not support autodetect, though. Likewise for the 32-bit Linux boxes I still have to build software on from time to time at work. (I just checked.)
So, still too soon to delete that from my muscle memory.
30 years of GNU Posted Sep 29, 2013 18:27 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link]
In case you're wondering, the machines at work are running RHEL WS4 (with a 2.6.9 kernel, even!), and my webserver is older still, running RH7 and a 2.4.x kernel. :-)
30 years of GNU Posted Sep 29, 2013 18:32 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
Sweet. But that doesn't really remove the fact that bash completion makes the behavior confusing.
Similar things happen for mplayer where mplayer identifies files by magic but bash completion has a predefined list of possible media files which will forever be incomplete (since magic based detection is how the tool actually works).
30 years of GNU Posted Sep 29, 2013 19:51 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Individually programs that can extend or disable parts of bash completion as needed.
30 years of GNU Posted Sep 29, 2013 20:07 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
Sure. There is an infinite number of ways you can improve the completions.
But the fundamental complaint I was making there is that it increases complexity and makes it more inexplicable when it does fail.
Programs extending or disabling parts of it increase the complexity further and potentially just exacerbate the problem, because it makes the behavior even harder to mentally model.
30 years of GNU Posted Sep 29, 2013 20:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Providing more functionality always increases complexity. I think it is manageable in this case and it is optional anyway.
30 years of GNU Posted Sep 29, 2013 23:08 UTC (Sun) by marcH (subscriber, #57642) [Link]
It does not matter: life is too short.
30 years of GNU Posted Sep 29, 2013 23:07 UTC (Sun) by marcH (subscriber, #57642) [Link]
> If I type tar zxvf foo[TAB], the over-fancy completion rules won't complete the filename unless it's actually a tar.gz.
"over-fancy"? You are too kind. Whoever spend their time implementing this type of over-crazy stuff should go and find themselves something useful to do.
The only (but significant) superiority of a command line interface over a graphical one is the lack of boundaries: I can enter the most surprising and unusual command and the computer will just do it - no questions asked. bash_completion.d breaks this. bash_completion.d brings the "Cannot find a program to open your file, wanna search the Internet?" type of frustration from the graphical interface world into the command line. A very impressive feat.
The even crazier thing is: how come many distributions enable this by default?
30 years of GNU Posted Sep 30, 2013 9:21 UTC (Mon) by gowen (guest, #23914) [Link]
M-/ is your friend.
You can, of course rebind TAB to complete-filename and skip all the auto-completion. Use "help bind".
It's unfortunate you couldn't find it in the documentation, but its more unfortunate that your response to this was ranting about it on the internet, as if your opinion were the only sane/valid one.
30 years of GNU Posted Sep 30, 2013 11:36 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] [I]ts more unfortunate that your response to this was ranting about it on the internet, as if your opinion were the only sane/valid one. Yeah, well, that's just, like, your opinion, man. ;-)
30 years of GNU Posted Sep 30, 2013 12:19 UTC (Mon) by gowen (guest, #23914) [Link]
*chuckles*
Do you think there's a market for t-shirts showing Richard Stallman's face with the phrase "The Dude Abides" underneath?
30 years of GNU Posted Sep 30, 2013 17:58 UTC (Mon) by marcH (subscriber, #57642) [Link]
> It's unfortunate you couldn't find it in the documentation,
New, "smart" feature; so smart that now you must read documentation before using [TAB]...
You must be having a laugh, right?
30 years of GNU Posted Sep 30, 2013 15:32 UTC (Mon) by rgmoore (subscriber, #75) [Link] I can enter the most surprising and unusual command and the computer will just do it - no questions asked. Of course that's still true when you use command line completion. All that completion will do is make it easier to enter simple, predictable commands by hitting the
30 years of GNU Posted Oct 3, 2013 5:01 UTC (Thu) by k8to (subscriber, #15413) [Link]
I really like the bash completion fu, and I think it is probably better (more convenient) for almost everyone. But it does have awkward corners, and makes using the shell more complicated, so you might be right that it should be off by default.
I certainly didn't mind manually enabling it on Debian.
30 years of GNU Posted Oct 3, 2013 5:16 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
It probably would have been really awesome if it were just on another key instead of replacing the nice deterministic one. I've personally never found it useful, but I could imagine that someone might. My frustration was that I found that it greatly degraded something that was useful to everyone, and resulted in some unwelcome techsupport burden when it hit other people that haven't turned it off yet.
The responses here about using alt-/ to get the explicable behavior back are great. I'm not sure how I ever would have discovered that, since that difference in behavior is not pointed out in the bash man-page.
30 years of GNU Posted Oct 3, 2013 6:45 UTC (Thu) by k8to (subscriber, #15413) [Link]
I don't remember how I learned it. I think it might have been in the README.Debian files for the bash completion package that I had to manually install.
bash's command line behavior is a complicated interplay between libreadline and bash and your configfiles. It's pretty hard to learn about in general.
30 years of GNU Posted Oct 3, 2013 11:15 UTC (Thu) by khim (subscriber, #9252) [Link] The responses here about using alt-/ to get the explicable behavior back are great. I'm not sure how I ever would have discovered that, since that difference in behavior is not pointed out in the bash man-page. Really? That's strange: it's explained here:
One of the best things WRT GNU project is it's documentation: it's usually pretty well-written. At least user-facing one. Bash is not an exception. P.S. There are many different way to complete your text in
30 years of GNU Posted Oct 4, 2013 22:47 UTC (Fri) by marcH (subscriber, #57642) [Link]
> And of course TAB always meant “smart completion”. Only usually it was less “smart” than it is today.
Which means it Just Worked.
I did not realize this was called "smart completion". Now I completely understand the connection with Microsoft Word where the very first required is to immediately disable all the so-called "smart" features ("smart" quotes, "smart" initials, "smart" selection,...) in order to be allowed to type anything unusual that Microsoft did not expect.
Exactly the same kind of "smartness".
30 years of GNU Posted Oct 3, 2013 6:14 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
I'll be honest. When I first noticed the completion-fu, I was impressed. And most of the time, it does not bother me. But, when it gets in the way of something basic that I think should 'just work,' it incites my 'nerd rage.'
As an architect (both chip and software), I understand the desire to make the on-ramp to working with any particular platform shallower. I /also/ understand the frustration when the 'straightforward, dumb thing' gets usurped by the 'smart, but misapplied thing' (such as my tar example earlier).
I am officially on the fence, truth be told. I grew up with simpler behavior, and find less to complain about with it. The more complex completion.d behavior is definitely very clever, but is also more frustrating at times.
30 years of GNU Posted Sep 30, 2013 0:02 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]
> That one drives me nuts, personally. For example, suppose I download a
> compressed tarball, not noticing if it's foo.tar.gz, foo.tar.bz2, or > foo.tar.xz. If I type tar zxvf foo[TAB], the over-fancy completion rules > won't complete the filename unless it's actually a tar.gz.
Use Alt+/ to force completion, if "smart" completion fails.
The other trick is to add to /etc/inputrc:
Two really useful cases for tab completion are with the package-manager:
30 years of GNU Posted Sep 30, 2013 11:44 UTC (Mon) by cortana (subscriber, #24596) [Link]
> Use Alt+/ to force completion, if "smart" completion fails.
Sorry for the low-content post but... THANK YOU SO MUCH FOR THIS!
completion Posted Sep 30, 2013 12:53 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
scp completion is rather dangerous, here's how:
1. Set a remote machine to disable SSH connections from hosts which pester with invalid credentials because maybe they're "script kiddies"
2. Change the credentials somewhere
3. Try to use SCP completion. Whack tab a few times wondering why it's not working
4. Congratulations you are now locked out of the remote machine with no clue as to what happened.
A systems administrator we hired locked himself out of his home systems this way, very amusing.
completion Posted Oct 3, 2013 5:07 UTC (Thu) by k8to (subscriber, #15413) [Link]
I'm not a fan of log-into-remote-systems-on-tab-complete for sure. If nothing else, it introduces *crazy* latency into tab completion, which isn't really very pleasant.
As for the script-kiddy lockout, the sane thing to do is expire that kind of thing after some time interval, possibly progressive, so that once you realized you screwed up you just wait 30 minutes and can get back in.
If one is so dense as to keep spamming it over and over for over 30 minutes, well... maybe the lockout could work to teach one lessons in patience and care. :-D I know a younger me could probably have used them.
30 years of GNU Posted Sep 29, 2013 10:38 UTC (Sun) by nix (subscriber, #2304) [Link]
bash_completion.d is for pikers. I use zsh completion, because no completion system is complete unless it's a double-layer system with the top layer and consisting of bytecompiled shell. :) (Also, I like the fuzzy and directory completions. I typo a lot.)
|
|||||||||||||