sudo -i restituisce un errore

Quando provo a passare a root usando sudo -iottengo l'errore /var/tmp/sclDvf3Vx: line 8: -i: command not found... Tuttavia, su -funziona che continuerò a utilizzare. Non sono affatto un amministratore di sistema Linux, quindi l'ambiente è ancora piuttosto nebbioso. Immagino che le mie domande siano:

Perché viene generato l'errore?
Qual è la differenza tra i due comandi?
Perché dovresti usarne uno sopra l'altro?

Aggiornare:

Sto usando la versione di CentOS: CentOS versione 6.6 (Final)

Ecco l'output di alcuni comandi che mi è stato chiesto di eseguire, nei commenti qui sotto.

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

Aggiornare:

Questo è stato aggiunto al mio utente non root ~ / .bashrc qualche tempo fa perché avevo bisogno del supporto C ++ 11. Quando lo commento, rispondo, posso eseguire sudo -i bene senza errori.

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

— th3v0id
fonte

Sei sicuro che -sia davvero un (ASCII) -?

— Steeldriver,

Qualcuno ha creato un aliasper il tuo sudocomando?

— GarethTheRed,

Ok, quindi hai un comando locale chiamato sudoche non è il normale comando sudo. Dato che non comprende le opzioni di sudo, chiaramente non è una cosa standard. Usa /usr/bin/sudoo chiedi ai tuoi amministratori locali (che avrebbero dovuto dirtelo quando ti hanno dato poteri sudo).

— Gilles 'SO- smetti di essere malvagio' il

Sto votando per chiudere questa domanda come fuori tema perché riguarda un programma sconosciuto, probabilmente di produzione propria, con il quale Internet non può fare a meno.

— Gilles 'SO- smetti di essere malvagio' il

Non penso che questo sia coltivato in casa, è la versione di CentOS del set di strumenti per sviluppatori RH : people.centos.org/tru/devtools-1.1 . Presumibilmente qualcuno su Internet lo sa.

— Michael Homer,

Risposte:

Dai commenti e dalle tue ulteriori indagini sembra che il tuo devtoolset stia modificando il PATH. Sfortunatamente questo include quello che sembra essere un comando sudo vecchio o rotto.

Vale la pena provare a modificare il devtoolset includendolo in .bashrcquesto modo, quindi riconnettersi nuovamente:

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

— roaima
fonte

Invece di aggirare il wrapper di sudo rotto di SCL, l'ho disabilitato.

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

L'aggiunta di una nuova riga alla fine del file assicura che non venga sovrascritto dai successivi aggiornamenti di Yum, quindi lo rendo non eseguibile.

Ho installato il set di strumenti dev per ottenere le versioni moderne di gcc e c ++ su RHEL 6 e non ho avuto problemi a compilare il codice senza il falso sudo nel mix.

— miken32
fonte

Ho avuto problemi simili con sudo -Eflag dopo aver usato devtoolset-4. Non dovresti aggiungere -Eflag in quel caso, perché è aggiunto nello /opt/rh/devtoolset-4/root/usr/bin/sudoscript wrapper, ecco il suo contenuto:

#! /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"

— Vadim Kotov
fonte