| |||||||||||||
30 years of GNU30 years of GNUPosted Oct 3, 2013 5:01 UTC (Thu) by k8to (subscriber, #15413)In reply to: 30 years of GNU by marcH Parent article: 30 years of GNU
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.
(Log in to post comments)
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.
|
|||||||||||||