sudo auto-completion

Originally Posted by orbea Have you tried current? This seems to just work for me, I don't recall doing anything to make this work either.

No I hadn't. Now that I have, I find that "sudo upgr" works in a non-graphical login. However with a graphical login it was still not working unless I made the shell a login shell. This gave the clue that contents of /etc/profile.d/ (which includes bash_completion.sh) were not being sourced. Adding

. /etc/profile.d/bash_completion.sh

to my .bashrc enabled "sudo upgr" to complete as expected.

Subsequently, I found the same result in 14.2, so I think that's the answer to OP's question: either use login shells or source /etc/profile.d/bash_completion.sh

chris

@abga, what you are writing seems to reflect your personal opinion, but is technically not correct.

If

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

is set in the sudo configuration, no 'admin' script will ever break.

My question was only related to the autocompletion and as @Poprocks has answered I have provided enough information to understand it like that (btw. she is correct).

The hints by @chris.willing helped, concerning the inclusion of the profile script.

Thanks all for your help.

Lioh

Originally Posted by chris.willing I think that just sets up the PATH variable for when the target command is eventually being run, in case a script may call other commands not in the normal PATH.

yeah, I think you are right,
this seems related to the search path
/usr/share/bash-completion/bash_completion

# This function checks whether we have a given program on the system.
#
_have()
{
    # Completions for system administrator commands are installed as well in
    # case completion is attempted via `sudo command ...'.
    PATH=$PATH:/usr/sbin:/sbin:/usr/local/sbin type $1 &>/dev/null
}

@abga just seems to be stuck in the past
https://ubuntuforums.org/showthread....26#post6188826
^^ from 2008

compare these

sudo env
sudo bash -c env
sudo -i
    env
su -c env
su
    env
su -
    env
su -c bash -c env

I'm sure I've missed some

11 years on and things are different

Originally Posted by lioh @abga, what you are writing seems to reflect your personal opinion, but is technically not correct. If Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" is set in the sudo configuration, no 'admin' script will ever break. My question was only related to the autocompletion and as @Poprocks has answered I have provided enough information to understand it like that (btw. she is correct).

What I was advising you directly in my post #2 seems to be the opinion of the Slackware developers, provided the link to the documentation in my reply to Poprocks. If you choose to ignore the documentation and the recommended way Slackware is to be managed with the help of the root account, believing that you're a better user (mentioned this sort of users in my replies to Firerat), I only hope that you'll be successful in your procedures and won't break your system.
I also mentioned the necessity for the root's $PATH, as a minimum requirement, and indeed, your original question contained enough information showing that you're attempting administration tasks with sudo.

Good luck!

If you are referring to: https://docs.slackware.com/slackware...ation_overview I cannot see any point there for using su - over sudo. It states:

The “root” user is not the account which you are going to use as a matter of routine. Root is meant for system maintenance and configuration, software upgrades and the like.

which could also indicate to use sudo instead. Imho using sudo or su is just a matter of taste and there is no 'Slackware way to go' on that. But that's just a philosophical discussion and I am not so much into it. Anyhow, my question has been answered in the meanwhile.

Originally Posted by lioh If you are referring to: https://docs.slackware.com/slackware...ation_overview I cannot see any point there for using su - over sudo. It states: which could also indicate to use sudo instead. Imho using sudo or su is just a matter of taste and there is no 'Slackware way to go' on that. But that's just a philosophical discussion and I am not so much into it. Anyhow, my question has been answered in the meanwhile.

yeap, no problem with sudo

odd sudo behaviour in 2008 has been fixed

Originally Posted by Firerat odd sudo behaviour in 2008 has been fixed

Is that an assumption? Or is it based on some evidence, maybe your experience in the Slackware environment (incl. env. variables and the packages versions Slackware is providing)?
I'm asking this because in post #8 I mentioned a workaround, again, corrective for the OP with his initial simple sudo command:

Using sudo and inheriting root's environment might be an alternative

and deliberately omitted (not that courageous like montagdude in post #12 - using "should" )to provide the command:

sudo -i

because before I wrote that post I ran some simple test, as I'm usually doing (when it's possible) before giving advice, with env & set & printenv in a native root interactive shell and with the help of sudo -i
Briefly compared the results and noticed some inconsistencies, the $PATH was consistent, but there were some env. variables (a very few) that were not matching. I didn't bother to study them in more detail, they could be insignificant, but this drove me to read the sudo man - ENVIRONMENT section and learned that sudo has some internal logic - discretionary to some extent. Then stumbled upon this article:
https://unix.stackexchange.com/quest...-i-and-sudo-su
And this one from 2015 - from where I picked&provided the 2008 Ubuntu forum link:
https://unix.stackexchange.com/quest...i-vs-sudo-bash

Now, I won't spend more time on this, because it looks like I'm not able to help the OP due to his limited understanding of the English language, but as with the case with Poprocks, I'm concerned about your previous post and hope you can also provide some evidence for your statements.

____


With this short study/refresh (I haven't used it for ages) in the internals of sudo and all its historical (and present) issues and limitations, I believe that Slackware's decision not to use it for administrative tasks was a wise one. BTW there's no mention of sudo in the Slackware documentation, but all the operations are described to be executed as root.

You would like proof it is not broken?
can one prove a negative?

show us something that *is* broken with sudo. That will disprove it is not broken.

you may well be correct.

As a matter of fact I did believe you ( in post # whatever ) until I noted that you gave no example of something which didn't work with sudo.

I'm asking this because in post #8 I mentioned a workaround, again, corrective for the OP with his initial simple sudo command: Using sudo and inheriting root's environment might be an alternative and deliberately omitted (not that courageous like montagdude in post #12 - using "should" )to provide the command: sudo -i because before I wrote that post I ran some simple test

hmm
[Pedantry]
English is tricky, so easy to get wrong.

"I mentioned a workaround"
should be
"I mentioned a possible workaround"
due to the use of the word "might"

You tested it but wasn't certain?

[/Pedantry]


Seriously
If you do have an actual example I would love to look at it.

either way, let us synchronize our feet and continue to walk our paths cheerfully

@lioh:

Using both su and sudo is appropriate. I use both daily.

I wonder if there is another way to make auto-completion work for sudo commands which are outside the users $PATH?

Type the full path to the command: sudo /sbin/upgr -Tab.

I don't really want to add this to the users $PATH variable

If you change your mind, throw something like this into /etc/profile.d/i_trust_myself.sh:

# Add /usr/local/bin to $PATH.
if [ "$(echo $PATH | grep /usr/local/bin)" = "" ]; then
  PATH="$(echo $PATH | sed 's|/usr/bin:|/usr/local/bin:/usr/bin:|')"
fi
# Add sbin directories to non-root $PATH.
if [ "$(echo $PATH | grep /usr/local/sbin)" = "" ]; then
  PATH="$(echo $PATH | sed 's|/usr/local/bin:|/usr/local/sbin:/usr/local/bin:|')"
  PATH="$(echo $PATH | sed 's|/usr/bin:|/usr/sbin:/usr/bin:|')"
  PATH="$(echo $PATH | sed 's|:/bin:|:/sbin:/bin:|')"
fi

Originally Posted by Firerat You would like proof it is not broken? can one prove a negative? show us something that *is* broken with sudo. That will disprove it is not broken. you may well be correct. As a matter of fact I did believe you ( in post # whatever ) until I noted that you gave no example of something which didn't work with sudo. hmm [Pedantry] English is tricky, so easy to get wrong. "I mentioned a workaround" should be "I mentioned a possible workaround" due to the use of the word "might" You tested it but wasn't certain? [/Pedantry] Seriously If you do have an actual example I would love to look at it. either way, let us synchronize our feet and continue to walk our paths cheerfully

I asked you to provide some evidence about your statement in the context of the sudo usage on Slackware. It's a Slackware support forum & thread. I also provided details about my short study and the tests I ran. You could consider them as the requested "example", pick up where I left and do some investigation if you have time, play with sudo -i, check the environment and test all the administrative scripts. I don't and I also don't attempt to break things that were properly designed, documented and working well. Never tried to qualify as a better "user", sorry.
With respect to the English language, it was an observation and reaction (I stopped caring) about OP's interpretation in post #20.

Sorry, cannot follow your rubbish with the corrections, I only know I ate one "s" in "test", I should have used the plural form, but didn't bother to correct it. However, I'd like to ask you, if you're so kind and capable (more importantly), to stay away from personal attacks, act professional and provide some evidence for your statements.

I asked for an example of something that doesn't work.
if you cannot provide that, it is evidence that sudo "is fine".

hold on, I *might* have one
/usr/share/mkinitrd/ # we don't need that bit for example

mkinitrd_command_generator.sh -k X.Y.Z | bash
# most people will do that wrong with sudo
sudo mkinitrd_command_generator.sh -k X.Y.Z | bash
# bash is not root
# they figure that out and
mkinitrd_command_generator.sh -k X.Y.Z | sudo bash
# wait, did that work?
# I honestly didn't expect that to work, I've always avoided that 
# I would 
sudo bash < <(mkinitrd_command_generator.sh -k X.Y.Z)
# habit I guess

but yeah, I can see how a "real" root shell would make that one easier
for someone unfamiliar with here docs

In English
"I mentioned a workaround"
means something different to
"I mentioned a possible workaround"

you stated you gave a workaround, but
"Using sudo and inheriting root's environment might be an alternative"
means it isn't a workaround, it is a possible workaround.

I suppose I could drop that if
"Using sudo and inheriting root's environment might be a <good|suitable|appropriate> alternative"

but as it was the two statements do not reconcile.

and yes, I read test but assumed tests
what tests do you do? ones not unlike those in #18 ?
great minds and all that

I do like that 2008 link you gave
especially the guy who told his boss doom and gloom stories of "viruses infecting the windows network" if he used sudo, just so he wouldn't use sudo.
delightfully apt I thought.