Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #223405 > unrolled thread

Need commands

Back to article view | Back to linux.debian.user

Contents

  Need commands ROHIT SONI <rs499647@gmail.com> - 2020-06-13 07:10 +0200
    Re: Need commands deloptes <deloptes@gmail.com> - 2020-06-13 08:20 +0200
    Re: Need commands Richard Owlett <rowlett@cloud85.net> - 2020-06-13 12:50 +0200
    Re: Need commands Teemu Likonen <tlikonen@iki.fi> - 2020-06-13 13:20 +0200
      Re: Need commands Mike McClain <mike.junk.46@att.net> - 2020-06-14 06:10 +0200
        Re: Need commands David Wright <deblis@lionunicorn.co.uk> - 2020-06-14 17:20 +0200
    Re: Need commands mick crane <mick.crane@gmail.com> - 2020-06-14 13:30 +0200
      Re: Need commands <tomas@tuxteam.de> - 2020-06-14 13:50 +0200
        Re: Need commands mick crane <mick.crane@gmail.com> - 2020-06-14 14:20 +0200
        Re: Need commands mick crane <mick.crane@gmail.com> - 2020-06-14 14:40 +0200
          Re: Need commands <tomas@tuxteam.de> - 2020-06-14 15:50 +0200
            Re: Need commands Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-15 14:10 +0200
              Re: Need commands <tomas@tuxteam.de> - 2020-06-15 14:10 +0200
          Re: Need commands davidson <davidson@freevolt.org> - 2020-06-16 10:50 +0200
            bash-completion pros/cons (was: Re: Need commands) l0f4r0@tuta.io - 2020-06-16 13:00 +0200
              Re: bash-completion pros/cons (was: Re: Need commands) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-06-16 13:30 +0200
                Re: bash-completion pros/cons (was: Re: Need commands) l0f4r0@tuta.io - 2020-06-16 14:00 +0200
                  Re: bash-completion pros/cons (was: Re: Need commands) <tomas@tuxteam.de> - 2020-06-16 15:00 +0200
                    Re: bash-completion pros/cons The Wanderer <wanderer@fastmail.fm> - 2020-06-16 15:20 +0200
                      Re: bash-completion pros/cons David Wright <deblis@lionunicorn.co.uk> - 2020-06-16 21:50 +0200
                        Re: bash-completion pros/cons Anders Andersson <pipatron@gmail.com> - 2020-06-17 10:10 +0200
                          Re: bash-completion pros/cons David Wright <deblis@lionunicorn.co.uk> - 2020-06-18 21:20 +0200
                            Re: bash-completion pros/cons David Wright <deblis@lionunicorn.co.uk> - 2020-06-18 22:20 +0200
                              Re: bash-completion pros/cons David Wright <deblis@lionunicorn.co.uk> - 2020-06-19 04:20 +0200
                        Re: bash-completion pros/cons <tomas@tuxteam.de> - 2020-06-17 10:40 +0200
                          Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-17 12:00 +0200
                            Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-17 13:20 +0200
                              Re: Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-17 13:40 +0200
                                Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-17 13:40 +0200
                                  Re: Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-17 14:00 +0200
                                    Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-17 14:30 +0200
                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-17 14:40 +0200
                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-17 19:20 +0200
                                        Re: Disabling recommends - was [Re: bash-completion pros/cons] David Wright <deblis@lionunicorn.co.uk> - 2020-06-17 21:20 +0200
                                          Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-17 21:50 +0200
                                            Re: Disabling recommends - was [Re: bash-completion pros/cons] David Wright <deblis@lionunicorn.co.uk> - 2020-06-18 21:20 +0200
                                              Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-19 17:30 +0200
                                                Re: Disabling recommends - was [Re: bash-completion pros/cons] Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-19 23:40 +0200
                                                Re: Disabling recommends - was [Re: bash-completion pros/cons] Tom Dial <tddial@comcast.net> - 2020-06-19 23:40 +0200
                                                  Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-20 01:20 +0200
                                                  Re: Disabling recommends - was [Re: bash-completion pros/cons] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-20 17:00 +0200
                                                    Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-20 19:40 +0200
                                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-20 21:20 +0200
                                                        Re: Disabling recommends - was [Re: bash-completion pros/cons] Tom Dial <tddial@comcast.net> - 2020-06-21 01:10 +0200
                                                          Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-21 14:40 +0200
                                            Re: Disabling recommends - was [Re: bash-completion pros/cons] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-19 05:20 +0200
                                              Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-19 17:00 +0200
                                    Re: Disabling recommends - was [Re: bash-completion pros/cons] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-19 05:30 +0200
                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-19 13:30 +0200
                                        Re: Disabling recommends - was [Re: bash-completion pros/cons] David Wright <deblis@lionunicorn.co.uk> - 2020-06-19 16:40 +0200
                                          Re: Disabling recommends - was [Re: bash-completion pros/cons] Andy Smith <andy@strugglers.net> - 2020-06-19 19:20 +0200
                                          Re: Disabling recommends - was [Re: bash-completion pros/cons] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-20 17:10 +0200
                                        Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-19 19:50 +0200
                                Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-18 02:00 +0200
                                  Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-18 10:20 +0200
                                    Re: Disabling recommends - was [Re: bash-completion pros/cons] Richard Owlett <rowlett@cloud85.net> - 2020-06-18 13:50 +0200
                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-18 14:50 +0200
                                        Re: Disabling recommends - was [Re: bash-completion pros/cons] Brian <ad44@cityscape.co.uk> - 2020-06-18 21:00 +0200
                                          Re: Disabling recommends - was [Re: bash-completion pros/cons] <tomas@tuxteam.de> - 2020-06-18 21:10 +0200
                                      Re: Disabling recommends - was [Re: bash-completion pros/cons] David Wright <deblis@lionunicorn.co.uk> - 2020-06-18 21:20 +0200
                  Re: bash-completion pros/cons (was: Re: Need commands) davidson <davidson@freevolt.org> - 2020-06-18 09:30 +0200
                    Re: bash-completion pros/cons (was: Re: Need commands) <tomas@tuxteam.de> - 2020-06-18 10:20 +0200
              Re: bash-completion pros/cons (was: Re: Need commands) davidson <davidson@freevolt.org> - 2020-06-18 09:10 +0200
                Re: bash-completion pros/cons (was: Re: Need commands) l0f4r0@tuta.io - 2020-06-18 20:40 +0200
            Re: Need commands mick crane <mick.crane@gmail.com> - 2020-06-16 13:20 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#223405 — Need commands

[Multipart message — attachments visible in raw view] — view raw

Hello sir
I need full commands for 2020.2 gnu/linux rolling kali tty1

[toc] | [next] | [standalone]

#223408

ROHIT SONI wrote:

> I need full commands for 2020.2 gnu/linux rolling kali tty1

I need 1000000,- €

[toc] | [prev] | [next] | [standalone]

#223427

On 06/12/2020 11:42 PM, ROHIT SONI wrote:
> Hello sir
> I need full commands for 2020.2 gnu/linux rolling kali tty1
> 

<Chuckle> Though Kali is derived from Debian, it is *NOT* Debian.
[q.v. https://en.wikipedia.org/wiki/Kali_Linux ]

[toc] | [prev] | [next] | [standalone]

#223429

[Multipart message — attachments visible in raw view] — view raw

ROHIT SONI [2020-06-13T10:12:06+05:30] wrote:

> I need full commands for 2020.2 gnu/linux rolling kali tty1

List all commands in a terminal program and Bash shell:

    ls -l {/usr,}/{s,}bin/; help

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

[toc] | [prev] | [next] | [standalone]

#223466

On Sat, Jun 13, 2020 at 02:01:06PM +0300, Teemu Likonen wrote:
> ROHIT SONI [2020-06-13T10:12:06+05:30] wrote:
>
> > I need full commands for 2020.2 gnu/linux rolling kali tty1
>
> List all commands in a terminal program and Bash shell:
>
>     ls -l {/usr,}/{s,}bin/; help
>
> --
> /// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
> // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

Way to go, Mr. Likonen.
Thumbs up.
Mike

--
Always remember:
    It is a mathematical certainty that half the people
        in this country are below average in intelligence!

[toc] | [prev] | [next] | [standalone]

#223482

On Sat 13 Jun 2020 at 21:23:51 (-0600), Charles Curley wrote:
> -- 
> Does anybody read signatures any more?

On Sat 13 Jun 2020 at 22:36:15 (-0700), Mike McClain wrote:
> 
> --
> Always remember:
>     It is a mathematical certainty that half the people
>         in this country are below average in intelligence!

If that's meant to be a signature, you should put one space after the --
like the example above.

s/average/median/ is the mathematical certainty. It's a well-known
fact that most people have an above-average number of legs.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#223473

On 2020-06-13 19:51, Darac Marjal wrote:
...
> The full list of commands depends on what's installed, but you can
> retrieve that list by opening a terminal and typing:
> 
>     compgen -ac

what are these words that begin with the underscore ?

__load_completion
__ltrim_colon_completions
__parse_options
__reassemble_comp_words_by_ref
_allowed_groups
_allowed_users
_available_interfaces
_cd
_cd_devices
_command

mick

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#223474

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 14, 2020 at 12:23:15PM +0100, mick crane wrote:
> On 2020-06-13 19:51, Darac Marjal wrote:
> ...
> >The full list of commands depends on what's installed, but you can
> >retrieve that list by opening a terminal and typing:
> >
> >    compgen -ac
> 
> what are these words that begin with the underscore ?
> 
> __load_completion
> __ltrim_colon_completions
> __parse_options
> __reassemble_comp_words_by_ref
> _allowed_groups
> _allowed_users
> _available_interfaces
> _cd
> _cd_devices
> _command

I don't have those. Most probably they are shell functions defined for your
session. Just issue the command

  type __load_completion

to shed light on that.

Which package or program defines them is anyone's guess, but you can try
to look into your shell initialization files (i.e. /etc/profile, ~/.bashrc,
all those mentioned in the FILES section of man bash [1]) to learn more.

Cheers

[1] or whatever shell is yours.

-- tomás

[toc] | [prev] | [next] | [standalone]

#223475

On 2020-06-14 12:42, tomas@tuxteam.de wrote:
> On Sun, Jun 14, 2020 at 12:23:15PM +0100, mick crane wrote:
>> On 2020-06-13 19:51, Darac Marjal wrote:
>> ...
>> >The full list of commands depends on what's installed, but you can
>> >retrieve that list by opening a terminal and typing:
>> >
>> >    compgen -ac
>> 
>> what are these words that begin with the underscore ?
>> 
>> __load_completion
>> __ltrim_colon_completions
>> __parse_options
>> __reassemble_comp_words_by_ref
>> _allowed_groups
>> _allowed_users
>> _available_interfaces
>> _cd
>> _cd_devices
>> _command
> 
> I don't have those. Most probably they are shell functions defined for 
> your
> session. Just issue the command
> 
>   type __load_completion
> 
> to shed light on that.
> 
> Which package or program defines them is anyone's guess, but you can 
> try
> to look into your shell initialization files (i.e. /etc/profile, 
> ~/.bashrc,
> all those mentioned in the FILES section of man bash [1]) to learn 
> more.
> 
> Cheers
> 
> [1] or whatever shell is yours.
> 
> -- tomás

probably then is to do with sshing in to see what this "compgen" was.

mick

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#223476

On 2020-06-14 12:42, tomas@tuxteam.de wrote:
> On Sun, Jun 14, 2020 at 12:23:15PM +0100, mick crane wrote:
>> On 2020-06-13 19:51, Darac Marjal wrote:
>> ...
>> >The full list of commands depends on what's installed, but you can
>> >retrieve that list by opening a terminal and typing:
>> >
>> >    compgen -ac
>> 
>> what are these words that begin with the underscore ?
>> 
>> __load_completion
>> __ltrim_colon_completions
>> __parse_options
>> __reassemble_comp_words_by_ref
>> _allowed_groups
>> _allowed_users
>> _available_interfaces
>> _cd
>> _cd_devices
>> _command
> 
> I don't have those. Most probably they are shell functions defined for 
> your
> session. Just issue the command
> 
>   type __load_completion
> 
> to shed light on that.
> 
> Which package or program defines them is anyone's guess, but you can 
> try
> to look into your shell initialization files (i.e. /etc/profile, 
> ~/.bashrc,
> all those mentioned in the FILES section of man bash [1]) to learn 
> more.
> 
> Cheers
> 
> [1] or whatever shell is yours.
> 
> -- tomás

I wish I'd never looked now.
so they are functions defined in the actual bash code for other words to 
get the result of ?

mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#223478

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 14, 2020 at 01:38:29PM +0100, mick crane wrote:

[...]

> I wish I'd never looked now.

Why? Granted, curiosity kills the cat, they say. But that's what we
hackers and tinkerers thrive on, ain't it?

What's a life without learning?
> so they are functions defined in the actual bash code for other
> words to get the result of ?

OK. My hunch is that they have something to do with bash autocompletion.
Since they are functions, not files, it's hard to say which package
they come from (with on-board means, that is).

But there are way more powerful off-board means. Enter Debian Code Search:

  https://codesearch.debian.net/

Put __load_completion into that little box and... yes, it comes from
the package "bash-completion" (which I explicitly don't install: I
tried it once and didn't like it. Too much magic. But horses for courses,
as they say, too :)

Enjoy
-- tomás

[toc] | [prev] | [next] | [standalone]

#223499

On Sun, Jun 14, 2020 at 03:48:19PM +0200, tomas@tuxteam.de wrote:
> OK. My hunch is that they have something to do with bash autocompletion.
> Since they are functions, not files, it's hard to say which package
> they come from (with on-board means, that is).
> 
> But there are way more powerful off-board means. Enter Debian Code Search:
> 
>   https://codesearch.debian.net/

Bear in mind that the OP was running Kali, not Debian.  I don't know off
hand whether Kali makes changes to their bash-completion package, but
in any event, it's something to keep in mind when responding.

[toc] | [prev] | [next] | [standalone]

#223500

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 15, 2020 at 08:03:05AM -0400, Greg Wooledge wrote:
> On Sun, Jun 14, 2020 at 03:48:19PM +0200, tomas@tuxteam.de wrote:
> > OK. My hunch [...]

> Bear in mind that the OP was running Kali, not Debian.  I don't know off
> hand whether Kali makes changes to their bash-completion package, but
> in any event, it's something to keep in mind when responding.

Thanks for the heads-up, I wasn't aware (rough sleep schedule, currently :-/

In any case, my aim was to provide a fishing rod along with the fish ;-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#223531

[Multipart message — attachments visible in raw view] — view raw

On Sun, 14 Jun 2020, mick crane wrote:

> On 2020-06-14 12:42, tomas@tuxteam.de wrote:
>> On Sun, Jun 14, 2020 at 12:23:15PM +0100, mick crane wrote:
>>> On 2020-06-13 19:51, Darac Marjal wrote:
>>> ...
>>> >The full list of commands depends on what's installed, but you can
>>> >retrieve that list by opening a terminal and typing:
>>> >
>>> >    compgen -ac
>>> 
>>> what are these words that begin with the underscore ?
>>> 
>>> __load_completion
>>> __ltrim_colon_completions
>>> __parse_options
>>> __reassemble_comp_words_by_ref
>>> _allowed_groups
>>> _allowed_users
>>> _available_interfaces
>>> _cd
>>> _cd_devices
>>> _command
>> 
>> I don't have those. Most probably they are shell functions defined for your
>> session. Just issue the command
>>
>>   type __load_completion
>> 
>> to shed light on that.
>> 
>> Which package or program defines them is anyone's guess, but you can try
>> to look into your shell initialization files (i.e. /etc/profile, ~/.bashrc,
>> all those mentioned in the FILES section of man bash [1]) to learn more.
>> 
>> Cheers
>> 
>> [1] or whatever shell is yours.
>> 
>> -- tomás
>
> I wish I'd never looked now.
> so they are functions defined in the actual bash code for other words to get 
> the result of ?

Er, they look like shell functions that bash_completion (from package
"bash-completion") defines for the greater glory of Bash
Completionstan.

  $ apt-description bash-completion # Not a real command
  bash-completion - programmable completion for the bash shell
   bash completion extends bash's standard completion behavior to achieve
   complex command lines with just a few keystrokes.  This project was
   conceived to produce programmable completion routines for the most
   common Linux/UNIX commands, reducing the amount of typing sysadmins
   and programmers need to do on a daily basis.
  Homepage: https://github.com/scop/bash-completion

You can read about shell functions in general in the bash man page,
either briefly under section "SHELL GRAMMAR" in subsection "Shell
Function Definitions", or at greater length in the section
"FUNCTIONS".

I hear some people find bash-completion helpful. Personally, though,
no. Do not want.

So, when using a system with bash-completion installed, I disable it
in my own accounts with two steps:

STEP 1

Create a file ~/.config/bash_completion containing the line "shopt -u
progcomp". (If you happen not to have a directory ~/.config already,
create one first.)

  $ echo "# Disable bash-completion" >> ~/.config/bash_completion
  $ echo "shopt -u progcomp" >> ~/.config/bash_completion

This makes /etc/profile.d/bash_completion.sh do nothing when it runs
(other than source your ~/.config/bash_completion), because
/etc/profile.d/bash_completion.sh is polite like that.

In order for this to be effective, the file you create in ~/.config
must have that precise name (with an underscore, not a hyphen), and it
must unset the progcomp shell option (which is what the line "shopt -u
progcomp" does).

/usr/share/doc/bash-completion/README.md.gz explains STEP 1 more
generally like so:

   The `profile.d` script provides a configuration file hook that can
   be used to prevent loading `bash_completion` on per user basis when
   it's installed system wide. To do this:

   1. Turn off programmable completion with `shopt -u progcomp` in
      `$XDG_CONFIG_HOME/bash_completion` (or
      `~/.config/bash_completion` if `$XDG_CONFIG_HOME` is not set)

   2. Turn it back on (for example in `~/.bashrc`) if you want to use
      programmable completion for other purposes.


STEP 2

Examine ~/.bashrc and look for any sections that enable
bash_completion, and comment them out:

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
# if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
#    . /etc/bash_completion

Both steps are required. The first keeps system-wide profile from
running bash_completion for you. The second keeps your ~/.bashrc from
running it for yourself.

After doing both, start a new bash session and check to see if

  $ typeset -F

still shows presence of the offending functions.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#223534 — bash-completion pros/cons (was: Re: Need commands)

Hi,

16 juin 2020 à 10:47 de davidson@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? 

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#223537 — Re: bash-completion pros/cons (was: Re: Need commands)

On Tue, Jun 16, 2020 at 12:54:58PM +0200, l0f4r0@tuta.io wrote:
> Hi,
> 
> 16 juin 2020 à 10:47 de davidson@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.

[toc] | [prev] | [next] | [standalone]

#223538 — Re: bash-completion pros/cons (was: Re: Need commands)

Hi Greg,

16 juin 2020 à 13:23 de wooledg@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

[toc] | [prev] | [next] | [standalone]

#223543 — Re: bash-completion pros/cons (was: Re: Need commands)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f4r0@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

[toc] | [prev] | [next] | [standalone]

#223544 — Re: bash-completion pros/cons

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-16 at 08:57, tomas@tuxteam.de wrote:

> On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f4r0@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.

I tend to concur with all of the above, but I have some additional
details to note.

There *are* contexts where I would find the ability to tab-complete
things other than paths to be useful; lengthy package names for apt-get
would be one example. For me, however, the cost in memory/CPU/etc.
footprint that has already been noted is enough to outweigh the benefit
that that would bring.


The biggest reason why I intentionally disable programmable completion,
however, is actually centered on the way it *changes* file-and-directory
path completion.

Without programmable completion, if I type the first few characters of a
directory name and press Tab, it will complete up to the name of that
directory (or to the point of uniqueness, if there are multiple files /
directories in the current context starting with that prefix) and then
stop.

With programmable completion, IIRC from the last time I checked (which
I'll admit was quite some years ago), in at least some contexts it will
instead complete all the way up to the end of the path. I specifically
recall a case when I had a directory /tmp/foo/bar/baz, and I wanted to
create /tmp/foo/bar/quux; I typed 'mkdir /tmp/f[tab]', with the
intention of typing 'b[tab]quux', and found that it had completed to the
end of 'baz' (and possibly to an actual filename within that directory)
and I had to backspace by some considerable amount to get to where I'd
wanted to be.

Cases where there is a multi-layer directory tree with only one item at
each level of the tree are comparatively rare, but ISTR that even when
there were multiple items at deeper levels it would still complete up to
the point of uniqueness, ignoring directory boundaries.

The additional keystrokes to tab-complete to the end of such a "only one
item in the parent directory" tree are, for me, more than worth it for
the additional level of control involved.


If I could selectively enable programmable completion for only specific
contexts where I've tried it out and decided that I want it, I'd
probably be happy to use it in at least some contexts. I haven't found a
good way of doing that, however, and haven't found it worth the bother
to dig all that deeply looking for one.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#223550 — Re: bash-completion pros/cons

[much snipping]

On Tue 16 Jun 2020 at 09:19:16 (-0400), The Wanderer wrote:
> On 2020-06-16 at 08:57, tomas@tuxteam.de wrote:
> > On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f4r0@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.

> > The only really useful autocompletion is actually file path 
> > autocompletion, and I have that without any extra packages.
> 
> I tend to concur with all of the above, but I have some additional
> details to note.
> 
> There *are* contexts where I would find the ability to tab-complete
> things other than paths to be useful; lengthy package names for apt-get
> would be one example. For me, however, the cost in memory/CPU/etc.
> footprint that has already been noted is enough to outweigh the benefit
> that that would bring.

It knows the names of a lot of subcommands, and can spell them.

> The biggest reason why I intentionally disable programmable completion,
> however, is actually centered on the way it *changes* file-and-directory
> path completion.

That can be annoying.

> Without programmable completion, if I type the first few characters of a
> directory name and press Tab, it will complete up to the name of that
> directory (or to the point of uniqueness, if there are multiple files /
> directories in the current context starting with that prefix) and then
> stop.
> 
> With programmable completion, IIRC from the last time I checked (which
> I'll admit was quite some years ago), in at least some contexts it will
> instead complete all the way up to the end of the path. I specifically
> recall a case when I had a directory /tmp/foo/bar/baz, and I wanted to
> create /tmp/foo/bar/quux; I typed 'mkdir /tmp/f[tab]', with the
> intention of typing 'b[tab]quux', and found that it had completed to the
> end of 'baz' (and possibly to an actual filename within that directory)
> and I had to backspace by some considerable amount to get to where I'd
> wanted to be.

It seems that I have to press [TAB] more than once for it to complete
the actual filename, but do use [ESC] [BACKSPACE] to rubout by word
rather than character.

But in any case, AIUI most of the above can be controlled by bash
itself, through things like shopt, readline, and even history.

Where bash-completion does get in the way for me is, for example,
where you download a file that's, say, a PDF but it arrives via wget
called, say, index_0001.3872359.html, for whatever reason.
So you type   xpdf inde [TAB]   and bash-completion refuses to
complete the name any further. If you're lucky, typing   * [RETURN]
will work, if there aren't any disruptive filenames which match
inde*, but in other cases the fastest workaround I know is to type
[HOME]less[SPACE][END] whereupon bash-completion is happy to match
any old filename for the less command, which you then rub out.

That's just one example, but it represents a whole class where it
seems that a bunch of files have disappeared because bash won't match them.

> If I could selectively enable programmable completion for only specific
> contexts where I've tried it out and decided that I want it, I'd
> probably be happy to use it in at least some contexts. I haven't found a
> good way of doing that, however, and haven't found it worth the bother
> to dig all that deeply looking for one.

Yes, good luck with that! It's probably deeply embedded in bash, and
even if you could hide/unhide some files, everything's likely to be
cached on efficiency grounds. It might be possible to set up some
xterms with tailored bashrc variables, to at least make completion
only work in certain instances. But then you're probably in the wrong
directory with the wrong history whenever you try to use one.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web