sudo -i zwraca błąd

Kiedy próbuję przełączyć się na rootowanie, sudo -iotrzymuję błąd /var/tmp/sclDvf3Vx: line 8: -i: command not found... Jednak su -działa, z którego będę nadal korzystać. W żadnym wypadku nie jestem administratorem systemu Linux, więc środowisko nadal jest dla mnie dość mgliste. Myślę, że moje pytania to:

Dlaczego zgłaszany jest błąd?
Jaka jest różnica między tymi dwoma poleceniami?
Dlaczego miałbyś używać jednego nad drugim?

Aktualizacja:

Używam wersji CentOS: CentOS wydanie 6.6 (wersja ostateczna)

Oto dane wyjściowe niektórych poleceń, które poproszono mnie o uruchomienie, w komentarzach poniżej.

type sudo : sudo is /opt/centos/devtoolset-1.1/root/usr/bin/sudo
sudo -V : /var/tmp/sclIU7gkA: line 8: -V: command not found
grep'^root:' /etc/passwd : root:x:0:0:root:/root:/bin/bash

Aktualizacja:

Zostało to dodane do mojego ~ ~ .bashrc użytkownika innego niż root, ponieważ potrzebowałem wsparcia dla C ++ 11. Kiedy to skomentuję, ponownie ssh, mogę uruchomić sudo -i w porządku bez żadnych błędów.

if [ "$(gcc -dumpversion)" != "4.7.2" ]; then 
  scl enable devtoolset-1.1 bash
fi

— th3v0id
źródło

Czy na pewno -jest to naprawdę (ASCII) -?

— steeldriver

Czy ktoś stworzył aliasdla twojego sudopolecenia?

— garethTheRed

Ok, więc masz lokalne polecenie o nazwie, sudoktóre nie jest normalnym poleceniem sudo. Biorąc pod uwagę, że nie rozumie on opcji sudo, wyraźnie nie jest to standardowa rzecz. Skorzystaj /usr/bin/sudoz usług lokalnych administratorów lub zapytaj ich (którzy tak naprawdę powinni ci o tym powiedzieć, gdy dali ci uprawnienia sudo).

— Gilles „SO- przestań być zły”

Głosuję za zamknięciem tego pytania jako nie na temat, ponieważ dotyczy ono jakiegoś nieznanego, prawdopodobnie domowego programu, w którym Internet nie jest w stanie pomóc.

— Gilles „SO- przestań być zły”

Nie sądzę, żeby w ogóle była to domowa uprawa , to wersja RH Developer Toolset CentOS : people.centos.org/tru/devtools-1.1 . Prawdopodobnie ktoś w Internecie o tym wie.

— Michael Homer

Odpowiedzi:

Z komentarzy i twoich dalszych badań wynika, że twój devtoolset modyfikuje PATH. Niestety obejmuje to coś, co wydaje się być starym lub zepsutym poleceniem sudo.

Warto spróbować zmodyfikować devtoolset w swoim w .bashrcten sposób, a następnie zalogować się ponownie:

if [ "$(gcc -dumpversion)" != "4.7.2" ]; then 
  scl enable devtoolset-1.1 bash
  PATH=/usr/bin:$PATH    # We need a working sudo
fi

— roaima
źródło

Zamiast obejść zepsute opakowanie sudo SCL, właśnie go wyłączyłem.

echo >> /opt/rh/devtoolset-2/root/usr/bin/sudo
chmod -x /opt/rh/devtoolset-2/root/usr/bin/sudo

Dodanie nowego wiersza na końcu pliku gwarantuje, że nie zostanie on nadpisany przez kolejne aktualizacje Yum, a potem po prostu sprawię, że nie będzie wykonywalny.

Zainstalowałem zestaw narzędzi deweloperskich, aby uzyskać nowoczesne wersje gcc i c ++ na RHEL 6 i nie miałem problemów z kompilacją kodu bez fałszywego sudo w miksie.

— miken32
źródło

Miałem podobne problemy z sudo -Eflagą po użyciu devtoolset-4. W takim przypadku nie należy dodawać -Eflagi, ponieważ jest ona dodawana w /opt/rh/devtoolset-4/root/usr/bin/sudoskrypcie opakowania, oto jej zawartość:

#! /bin/sh
# TODO: parse & pass-through sudo options from $@
sudo_options="-E"

for arg in "$@"
do
   case "$arg" in
    *\'*)
      arg= ;;
   esac
   cmd_options="$cmd_options '$arg'" 
done
exec /usr/bin/sudo $sudo_options LD_LIBRARY_PATH=$LD_LIBRARY_PATH PATH=$PATH scl enable devtoolset-4 "$cmd_options"

— Wadim Kotow
źródło