Re: bash-completion pros/cons (was: Re: Need commands)
Hi, 18 juin 2020 à 09:00 de david...@freevolt.org: > On Tue, 16 Jun 2020, l0f...@tuta.io wrote: > >> 16 juin 2020 à 10:47 de david...@freevolt.org: >> >>> I hear some people find bash-completion helpful. Personally, though, >>> no. Do not want. >>> >> Interesting/intriguing point of view. >> > I will remember this polite new way to call somebody a weirdo. > Don't get me wrong, I just meant that your previous answer aroused my curiosity. So I wanted to look deeper into it because maybe *I* was the weirdo after all ;p Thanks & Best regards, l0f4r0
Re: bash-completion pros/cons (was: Re: Need commands)
On Thu, Jun 18, 2020 at 07:25:40AM +, davidson wrote: > On Tue, 16 Jun 2020, l0f...@tuta.io wrote: [...] > >Maybe sometimes completion is not working as it should, nothing is > >perfect, but globally I think that it saves time more than its > >wastes. > > For those it suits, I am glad the package is available. Absolutely. Don't get me wrong. I decided it's not /for me/. I'm still glad it exists and I'm happy it's free. Cheers -- t signature.asc Description: Digital signature
Re: bash-completion pros/cons (was: Re: Need commands)
On Tue, 16 Jun 2020, l0f...@tuta.io wrote: [dd] 16 juin 2020 à 13:23 de wool...@eeg.ccf.org It's flaky and full of errors. (Many of these errors end up on the bash mailing lists as bug reports in bash, but nope, they're from bash-completion.) It bloats bash, using a lot of memory, and taking extra CPU and wall-clock time (may not be noticeable on modern hardware). That said, many people still find its benefits outweight its problems, and are quite happy with it. You get to make your own choice. Thanks. Proofreading the final command is not forbidden, right? ^^ That is always a good idea. And I prefer the mistakes that I find, the ones I correct, and the ones I overlook, to be my own. Because I learn best from my own mistakes. Maybe sometimes completion is not working as it should, nothing is perfect, but globally I think that it saves time more than its wastes. For those it suits, I am glad the package is available. It's probably more a conceptual/philosophical approach here ;) Agreed. -- https://news.ycombinator.com/item?id=12518471 alexk already addressed your concern: your keys, preferably issued by your org's CA (instead of being generated by you) should be short-lived, oftentimes for the duration of your "work shift". The tools listed above support this.
Re: bash-completion pros/cons (was: Re: Need commands)
On Tue, 16 Jun 2020, l0f...@tuta.io wrote: 16 juin 2020 à 10:47 de david...@freevolt.org: I hear some people find bash-completion helpful. Personally, though, no. Do not want. Interesting/intriguing point of view. I will remember this polite new way to call somebody a weirdo. Why would someone not be interested in autocompletion please? I am perfectly happy with autocompletion in general. Disabling bash-completion package does not mean one must peck out their bash command lines verbatim, character-by-character, as one must in grub rescue shell. Others have also pointed this out. I use a lot of the autocompletion (and command history) functionality described in bash(1), under the sections * READLINE:Completing * READLINE:Commands for Manipulating the History * HISTORY EXPANSION Those functions are agnostic: No matter what particular fragmentary command presently awaits completion (manual or otherwise), their behavior does not vary. And their very agnosticism is significant; it is largely why learning the shape of their behavior, and how to take advantage of it, has been worth the time and effort. Now consider the following: bash(1), section READLINE:Programmable Completion (AKA progcomp) [...] By default, if a compspec is found, whatever it generates is returned to the completion code as the full set of possible completions. The default bash completions are not attempted, and the readline default of filename completion is disabled. If the -o bashdefault option was supplied to complete when the compspec was defined, the bash default completions are attempted if the compspec generates no matches. If the -o default option was supplied to complete when the compspec was defined, readline's default completion will be performed if the compspec (and, if attempted, the default bash completions) generate no matches. [...] In other words, with progcomp I can (and the bash-completion package does) lay booby-traps that will override the behavior I've become so accustomed to. I might, in specialised context, choose to do this. But when any exceptional behavior has been specified by myself, then I know who to blame for the surprises. (And my own mistakes teach me things much more reliably than the mistakes of others.) In the shell I'm trying to play a nice orderly game of croquet. If there are going to be mines under the lawn, I want to install them myself, carefully. When I want someone to surprise me there is always NetHack. -- \ ' ., o O / It looks like you're writing a letter! ) / Would you like some help?/ Y : \.__./
Re: bash-completion pros/cons (was: Re: Need commands)
On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f...@tuta.io wrote: [...] > Maybe sometimes completion is not working as it should, nothing is perfect, > but globally I think that it saves time more than its wastes. Then just use it and be happy. And just accept that some (me, among others) are happier without :-) Yes, I've tried it. Yes, I think it's technically nifty. But no, it doesn't mesh well with the way I work. Even if it were bug-free, it wouldn't be "my" thing. I live by the command line, and there are roughly two classes of things I do: those I do very often, where history search is just unbeatable, and those I do rarely. For those I have a man page open, sometimes a notebook (in Emacs, but I disgress) to take notes and I proceed slowly. The top of the first class are candidates for automation and scripting. In the first class, I don't need autocompletion, since I know what I'm doing (heck, my muscle memory nearly knows. In the second class, autocompletion is a train wreck waiting to happen: I really *want* to know why each piece is there. The only really useful autocompletion is actually file path autocompletion, and I have that without any extra packages. > It's probably more a conceptual/philosophical approach here ;) For me it isn't. It is an eminently practical issue. Cheers -- t signature.asc Description: Digital signature
Re: bash-completion pros/cons (was: Re: Need commands)
Hi Greg, 16 juin 2020 à 13:23 de wool...@eeg.ccf.org > It's flaky and full of errors. (Many of these errors end up on the > bash mailing lists as bug reports in bash, but nope, they're from > bash-completion.) It bloats bash, using a lot of memory, and taking > extra CPU and wall-clock time (may not be noticeable on modern hardware). > > That said, many people still find its benefits outweight its problems, > and are quite happy with it. You get to make your own choice. > Thanks. Proofreading the final command is not forbidden, right? ^^ Maybe sometimes completion is not working as it should, nothing is perfect, but globally I think that it saves time more than its wastes. It's probably more a conceptual/philosophical approach here ;) Best regards, l0f4r0
Re: bash-completion pros/cons (was: Re: Need commands)
On Tue, Jun 16, 2020 at 12:54:58PM +0200, l0f...@tuta.io wrote: > Hi, > > 16 juin 2020 à 10:47 de david...@freevolt.org: > > > I hear some people find bash-completion helpful. Personally, though, > > no. Do not want. > > > Interesting/intriguing point of view. > Why would someone not be interested in autocompletion please? It's flaky and full of errors. (Many of these errors end up on the bash mailing lists as bug reports in bash, but nope, they're from bash-completion.) It bloats bash, using a lot of memory, and taking extra CPU and wall-clock time (may not be noticeable on modern hardware). That said, many people still find its benefits outweight its problems, and are quite happy with it. You get to make your own choice.
