Newsgroup: it.comp.os.linux.iniziare
Titolo: avviare nuova sessione bash con prompt modificato

~$ PS1='abc$ ' bash
~$
 
Sembra che la modifica non abbia avuto effetto. Perchè?
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 Sembra che la modifica non abbia avuto effetto. Perchè?
 
   Perché la shell si legge la definizione del prompt primario nei suoi 
 
file di iniziazione.
 
 
   Ciao,
 
 
Alessandro
 
 

 [-- Description: OpenPGP digital signature --]
 
 
 
 
Aggiungo di provare questo:
 
~$ export PS1='abc$ ' bash
 
 
-----------------
PS. x Alessandro
 
Ogni volta aprire i tuoi mesasggi è una scomodità,
non ho approfondito se c'è un modo per far in modo
che il mio newsreader "tin" non mi chieda conferma
su come gestire la tua pgp-signature... sicuramente
ci sarà, magari capita solo a me.
 
Qualcun altro rileva qualche problema/scomodità a
visualizzare i messaggi di Alesandro Selli?
 
Se qualcuno conosce il newsreaser in questione e sa
come impostare la cosa in modo da trattare le gpg al
volo automaticamente... grazie in anticipo

 volo automaticamente... grazie in anticipo
 
 
Io, uso tin[¹], ma non noto particolari problemi, i messaggi di Alessando mi
si aprono come tutti gli altri, salvo le 2 righe in basso che dicono che il
messaggio è firmato.
 
Tuttavia, se cerco di estrarre la key, mi risponde che è assente.
Il file che dovrebbe contenere la chiavi pubbliche è vuoto.
 
Il pgp, non lo uso mai, anche se l'ho installato e provato autoinviandomi un
paio di messaggi mail di prova con mutt.
 
 
 
 
[¹]
Version: tin 2.4.1 release 20161224 ("Daill") Dec 25 2016 21:44:05
Platform:
    OS-Name  = "linux-gnu"
Compiler:
    CC       = "cc"
    CFLAGS   = "-g -g -O2 -fdebug-prefix-map=/USR3/src/P/tin/tin-2.4.1=. -fstack-protector-strong -Wformat -Werror=format-security"
    CPP      = "cc -E"
    CPPFLAGS = "-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw"
Linker and Libraries:
    LD       = "cc"
    LDFLAGS  = "-g -Wl,-z,relro"
    LIBS     = "-lncursesw -ltinfo -luu -licuuc"
    PCRE     = "8.39 2016-06-14"
Characteristics:
    +DEBUG +NNTP_ABLE -NO_POSTING -BROKEN_LISTGROUP +XHDR_XREF
    -HAVE_FASCIST_NEWSADMIN +ENABLE_IPV6 -HAVE_COREFILE
    -NO_SHELL_ESCAPE -DISABLE_PRINTING -DONT_HAVE_PIPING -NO_ETIQUETTE
    +HAVE_LONG_FILE_NAMES +APPEND_PID +HAVE_MH_MAIL_HANDLING
    +HAVE_ISPELL -HAVE_METAMAIL +HAVE_SUM
    +HAVE_COLOR -HAVE_PGP -HAVE_PGPK +HAVE_GPG
    +MIME_BREAK_LONG_LINES +MIME_STRICT_CHARSET +CHARSET_CONVERSION
    +MULTIBYTE_ABLE -NO_LOCALE -USE_LONG_ARTICLE_NUMBERS
    +USE_CANLOCK -EVIL_INSIDE -FORGERY -TINC_DNS -ENFORCE_RFC1034
    -REQUIRE_BRACKETS_IN_DOMAIN_LITERAL -FOLLOW_USEFOR_DRAFT
 
 
-- 
 X SLMR 2.1a X Qualche Sardo mi traduce il fonema :  ADMAIORCA     (LS)

 ~$ export PS1='abc$ ' bash
 
Funziona.
Però dato che ci siamo, se puoi dare la spiegazione.

 ~$ export PS1='abc$ ' bash
 
   Questo non esegue il comando bash in un ambiente con la variabile PS1 
impostata ad 'abc$ '.  Questa riga esporta la variabile PS1 e le assegna 
il valore 'abc$ ' nella shell adesso in uso, non in una sottoshell.
 
   Non conosco tin, non posso aiutarti nella sua gestione della firma gpg.
 
 
Alessandro
 
 

 Però dato che ci siamo, se puoi dare la spiegazione.
 
In realtà non funziona, perché quella riga esegue soltanto export 
PS1='abc$ ', non manda in esecuzione una sottoshell.  Il comando finale 
 
bash è cioè ignorato.
 
 
Alessandro
 


Da me funziona:
 
$ PS1="pippo " bash
pippo
 
Il prompt diventa "pippo ".
 
Versione bash?
 
bye,
 
-- 
 
piergiorgio

 Però dato che ci siamo, se puoi dare la spiegazione.
 
perché invocando bash tu avvii un processo figlio, che non vede le variabili di ambiente impostate nel processo padre a meno di utilizzare la keyword export.

 
 
La sintassi:
 
VAR=valore programma
 
Dovrebbe mettere nell'ambiente di "programma"
la variabile "VAR" con "valore".
Almeno in "bash".
 
Lo usavo regolarmente per ri-definire CC o CPP
nelle chiamate a "make".
 
CC=icc make
 
Inoltre, come gia` scritto, a me:
 
PS1="pippo " bash
 
Funziona.
 
bye,
 
-- 
 
piergiorgio

 Sembra che la modifica non abbia avuto effetto. Perch�?
 
   Perch� la shell si legge la definizione del prompt primario nei suoi
 
file di iniziazione.
 
 
   Ciao,
 
 
Alessandro
 
 
--Press any key to go on.--
 
==========================================
 
 
 
Ecco...
Poi in coda a quanto sopra, dopo aver premuto
un tasto appare anche:
 
==========================================
 
Content-Description: OpenPGP digital signature
 
 
 
This message contains data in an unrecognized format, application/pgp-signature,
which can either be viewed as text or written to a file.
 
What do you want to do with the application/pgp-signature data?
1 -- See it as text
2 -- Write it to a file
3 -- Just skip it
4 -- Give another content type
 
==========================================
 
 
E anche lì devo premere un numero e dare invio,
se no resta tutto bloccato lì..
A quel punto compare ancora un'ulteriore richiesta
di conferma, ovvero il classico:
 
==========================================
 
Press <RETURN> to continue...
 
==========================================
 
 
 
A questo punto visualizzo anche io il messaggio
correttamente, con in fondo in più le due righe:
 
[-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
[-- Description: OpenPGP digital signature --]
 
Che non danno alcun fastidio e credo che fosse
quello che intendessi anche tu.  Quindi in pratica
a te salta tutta quella serie di conferme e
controconferme su come gestire la firma PGP...
 
 
Va be', alla fine è più una curiosità che un'esigenza
visti i pochi messaggi coinvolti.
Grazie per aver riportato il funzionamento regolare dal
tuo newsreader.
 
E scusate l'OT!


 
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

     [-- text/plain, encoding quoted-printable, charset: utf-8, 20 lines --]

Confermo!
ho fatto confusione io provando all'interno di una sessione screen con
aperte due schermate praticamente identiche (col prompt pulito):
 
- il mio comando ha modificato il prompt della prima schermata (ma la
  shell in uso era di fatto la stessa).
 
- poi quando ho premuto "exit" per uscire dalla supposta shell figlia
  in realtà sono uscito dall'intera schermata screen e mi sono ritrovato
  nell'altra schermata uguale, credendo di essere nella "shell genitrice".
 
Invece no: la sintassi giusta è:
 
VAR=valore comando
 
Il comando lavorerà con VAR impostata a "valore".
Però se "comando" è l'invocazione alla "bash", questa da me sembra fottersene,
e imposta il valore di "PS1" al suo default.
 
C'è da dire che io quel valore l'ho impostato in .bashrc:
 
$ cat .bashrc|grep PS1
export PS1="${GREEN}\u@\h:\w\$${RESET} "
 
Ecco a me salta fuori così.
Probabilmente la logica è questa:
 
- dal prompt imposto PS1=pippo
- lancio bash
- bash parte e vede impostato PS1=pippo
- ma in qualche modo sovrascrive il valore perché partendo va a leggere
  .bashrc
 
OK.
Sì, il problema nel mio caso è il file di configurazione ~/.bashrc
che sembra letto dopo l'impostazione della variabile dal prompt
nella shell genitrice e quindi va a sovrascriverlo con quello che
trova lì.
 
Per provare mi è bastato commentare la righa del .bashrc riportata
sopra.
 
Così funge:
------------------
default:~$ echo $$
19943
 
default:~$ PS1="pluto:\w$ " bash
 
pluto:~$ echo $$
20099
 
pluto:~$ exit
exit
 
default:~$ echo $$
19943
------------------
 
la var doppio dollaro "$$" restituisce l'ID del processo corrente, nel
nostro caso la shell in uso.
 
Lanciando bash anteposto dall'assegnazione della variabile PS1, il
prompt assume il nuovo aspetto, "pluto ecc" nell'esempio sopra.
Ma siamo sicuri di essere nella shell figlia?
 
Sì!
Perché il PID del processo corrento è diverso da quello di partenza.
Se usciamo dalla shell figlia ecco infatti che il prompt ritorna al
default e anche il PID corrente è di nuovo quello di prima.
 
Se non siete in una sessione screen probabilmente non è necessario
questo particolare perché se non foste nella shel figlia, quando date
exit vi si chiude il terminale. E vi accorgete che in realtà il giochino
non aveva funzionato del tutto.
 
Happy bash a tutti!

 GNU bash, versione 4.3.48(1)-release (x86_64-slackware-linux-gnu)
 
Beh, da me c'e` 5.1.0(1), ma il "trucco"
descritto credo sia abbastanza vecchio.
 
Che sia forse ora comunque di aggiornare?
 
bye,
 
-- 
 
piergiorgio


Se leggi l'altro mio messaggio c'è scritto perché non funzionava.
Colpa del .bashrc che sovrascrive l'assegnazione fatta dal prompt
quando parte la shell figlia, infatti quest'ultima va a leggere
quel file e sovrascrive l'allsegnazione con il valore trovato lì
dentro, che poi è ovviamente proprio quello di default.
 
Fai la prova eventualmente:
metti temporaneamente in .bashrc un bel 
 
export PS1=qualcosa
 
poi apri una shell nuova o fai il source del .bashrc insomma,
e infine esegui il lancio della shell figlia preceduto dall'impostazione
della var PS1=qualcosaltro.
 
In questo modo non dovrebbe funzionare come ci si aspetterebbe.

In date: Wed, 26 May 2021 22:28:12 on group: it.comp.os.linux.iniziare,

La mia versione è vecchiotta, ma tutta la pappardella non compare, solo le due
righe.
 
[-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
[-- Description: OpenPGP digital signature --]
 
Se provo con control-g per eseguire pgp nell'articolo, mi dice:
 
Article not signed and no public keys found
 
Ma, mi sembra, poi chiudo anch'io l'OT, che in un'altro gruppo, articoli
firmati li riconoscesse, ma parlo di un paio di anni fa.
 
 
-- 
 X SLMR 2.1a X All hope abandon, ye who enter messages here.

 Però dato che ci siamo, se puoi dare la spiegazione.
 
Ho viso che t'han gia' risposto, pero' ti do un'utility che mi son
fatto per quando vado in qualche sub-sub-sub..directory. Ho chiamato
il seguente script "chps1" e l'ho messo nella directory bin della
mia home.
-cite-
MINUS=$(echo $PS1 | grep '\[\\w\]')
MAIUS=$(echo $PS1 | grep '\[\\W\]')
 
if [ -n "$MINUS" -a -z "$MAIUS" ]; then
PS1="$(echo $PS1 | tr 'w' 'W') "
export PS1
return
fi
 
if [ -z "$MINUS" -a -n "$MAIUS" ]; then
PS1="$(echo $PS1 | tr 'W' 'w') "
export PS1
return
fi
-/cite-
 
E' del genere flip flop: se lo dai ti scrive solo il basename della
directory attiva, se lo ridai ritorna com'era prima (cioe' da me
cambia il path che mette tra quadre, opzione w <-> W).
 
Poi ho quest'altro, chps0, contro i nomi chilometrici di directory
aliene scricate:
-cite-
CENONCE=$(echo -n $PS1 | grep '\[\\w\]')
 
if [ -n "$CENONCE" ]; then
PS1="$(echo $PS1 | sed 's/\[\\w\]//') "
export PS1
return
fi
 
if [ -z "$CENONCE" ]; then
PS1="[\w]$(echo $PS1) "
export PS1
return
fi
-/cite-
 
Se te li vuoi provare, devi dare cosi':
 
[/usr/share/zoneinfo/Europe]yoda_$: . chps1
[Europe]yoda_$:
[Europe]yoda_$: . chps1
[/usr/share/zoneinfo/Europe]yoda_$:
 
 
[/usr/share/zoneinfo/Europe]yoda_$: . chps0
yoda_$:
yoda_$: . chps0
[/usr/share/zoneinfo/Europe]yoda_$:
 
perche' altrimenti lo script viene eseguito da una shell forkata, la
quale lo esegue si', solo che poi muore istantaneamente subito dopo,
tu non vedi nulla e il prompt della tua shell ("interativa" o "di
login") resta uguale a prima ciao
 
(occhio: NON devi metterci la permission (la x) d'esecuzione)
 
-- 
Yoda
 

   Non conosco tin, non posso aiutarti nella sua gestione della firma gpg.
 
La firma che apponi ai tuoi messaggi ha lo stesso valore come se fosse quella
di babbo natale.
Per autentificare un messaggio, il programma pgp (o equivalente), ha bisogno di
avere la tua chiave pubblica.
 
Senza avere la tua chiave pubblica in modo sicuro, il pgp non può certificare
che quello "scarbocchio" sia la tua firma autentica e che il messaggio sia
stato postato veramente da te (magari non ci hai fatto caso o non lo sai, ma
quello "scarabocchio" cambia ad ogni messaggio che posti, in quanto deve
certificare non solo il mittente, ma anche il contenuto).
 
Quindi, dove hai depositato la tua chiave pubblica?
Ce la puoi fornire personalemnte tramite canali sicuri?
Ma poi, se non abbiamo bisogno di contattarti privatamente per questioni che
richiedano una certa sicurezza, cosa ce ne facciamo della tua chiave pubblica?
 
Togli pure quella firma, che in questo contesto, gruppo pubblico, non ha senso.
 
Con simpatia, ciao.


 4 -- Give another content type
 
Mi ero dimenticato...
 
La cosa dipende non dal pgp, ma da tin che non può associare la "signature PGP" ad alcuna azione.
Guarda il file /etc/mime.types ed eventualmente anche in ~/.tin/mime.types.
 
 
-- 
--- PointMail 2.b8Demo
 * Origin: Il Raf... Point 12 di "The Rocky Horror BBS Show" (2:332/212.12)

 Però dato che ci siamo, se puoi dare la spiegazione.
 
ERRATA CORRIGE: in realtà non viene aperta una nuova bash, ma si rimane 
su quella corrente

 Se non siete in una sessione screen probabilmente non è necessario
 
Cos'è una sessione screen?

Il 26/05/21 21:00, Piergiorgio Sartor ha scritto:

Non funziona: ho provato meglio.

 Versione bash?
 
$ bash --version
GNU bash, versione 5.0.17(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.


 Cos'è una sessione screen?
 
Ah niente, "screen" è un programma che ti apre nel terminale una nuova
shell e da lì ti trovi dentro la "sessione screen", a quel punto ad
esempio con "ctrl-a + c" puoi aprirti una seconda shell che si
sovrappone alla prima, così puoi far girare sulla prima un programma e
contemporaneamente sulla seconda un altro programma, poi magari puoi
aprirne una terza e così via, insomma puoi avere al contempo N shell
sullo stesso terminale. Ovviamente si può passare dall'una all'altra
con "ctrl-a + ctrl-a", si può anche suddividere il terminale in due
o più parti e avere sott'occhio due o più shell ecc ecc... Infine dà
anche la possibilità di essere staccata (detach) l'intera sessione,
questa finisce in in background e lì resta anche facendo il logout
dell'utente. Poi la si può riagganciare lanciando "screen -r"...
Ok, mi pare che una spolverata ce l'hai per fare una ricerca se vorrai
approfondire.

 definita la variabile "PS1".
 
Non vi sono dubbi che il comando:
$ PS1='abc$ ' bash
apra una nuova shell.  Che poi venga effettivamente cambiato il prompt 
per questa subshell dipende da dove è impostata la variabile PS1.
 
Nella mia Slackware, a casa, PS1 è impostato nel file /etc/profile che 
viene eseguito solo al login.  Nella Debian del server all'università la 
variabile è impostata localmente in .bash_login (non posso modificare 
/etc/profile).
 
Il comando di cui sopra nella Slackware funziona come ci si 
aspetterebbe, cioè ridefinisce il prompt.
Nella Debian ciò non succede e l'effetto è che nella subshell viene 
impostato un prompt di default.
 
In entrambe le installazioni la bash è in versione 4.3.xx e mi sarei 
aspettato che dovesse funzionare in entrambi i casi visto che sia 
/etc/profile e ~/.bash_login vengono eseguiti esclusivamente al login - 
solo ~/.bashrc viene eseguito per ogni subshell.  Ma forse ricordo male 
e dovrei verificare nel man.
 
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 Guarda il file /etc/mime.types ed eventualmente anche in ~/.tin/mime.types.
 
Ce n'è un terzo di file, gli altri due da me non esistono, ma dal
manuale sembrano equivalenti a quest'altro, aprendolo rilevo che
l'associazione mime type - estensione è presente:
 
/etc/tin/mime.types
-------------------
application/pgp                 pgp
application/pgp-signature       pgp
-----------------------------------
 
Da te com'è fatto quel file?
O uno di quello equivalenti?
 
Sembrerebbe apposto no?
Non vi sono però specificate azioni su come trattare quella roba,
quindi non so...
D'altra parte tin lo dice chiaro:
"riconosco che si tratta di application/pgp-signature, ma non ho
un'azione di default su cosa farne, scegli l'azione manualmente".
 
Se anche tu usi tin, e da te non ti chiede quella conferma,
evidentemente da qualche parte avrai impostata un'azione che il reader
esegue automaticamente quando incontra un messaggio così firmato, così
a logica, ti torna?
 
 
 
 
PS.
Dal man 5 tin:
-----------------------------------
${TIN_HOMEDIR:-"$HOME"}/.mime.types
       /etc/mime.types
       /etc/tin/mime.types
 
             mime type / filename extension pairs
-------------------------------------------------


No, mi sa che ricordi bene.
 
Io sono su slackware 14.2 e in ~/.bashrc ho "export PS1=default", quindi
lanciando "PS1=pippo bash" apre la nuova shell (che non è una shell di
login e quindi non legge il ~/.profile nè /etc/profile, nè credo
/etc/profile.d/*.sh). Questa nuova shell avrebbe prompt pippo, ma non lo
ha perché al lancio va a leggere il bashrc e la variabile viene sovrascritta.
 
Se commento il ~/.bashrc, invece funziona tutto.
 
Hai provato un grep su PS1 nella dir home?
 
O anche qui qualcosa salta fuori:
 
$ grep PS1 /etc/profile.d/* 2>/dev/null
/etc/profile.d/32dev.sh:PS1='\u@\h (32bit):\w\$ '
/etc/profile.d/vte.sh:# Print a warning so that anyone who's added this
manually to his PS1 can adapt.
 
Però a dire il vero non so se 32dev.sh venga letto e quando e da chi...
 
 
 
Comunque si può provare a lanciare la bash con le opzioni che saltano la
lettura dei files di configurazione:
 
 
--noprofile
              Do not read either the system-wide startup file
              /etc/profile or any of the personal initialization
              files ~/.bash_profile, ~/.bash_login, or ~/.profile. By
              default, bash reads these files when it is invoked as a
              login shell (see INVOCATION below).
 
--norc
              Do not read and execute the personal initialization file
              ~/.bashrc if the shell is interactive. This option is on
              by default if the shell is invoked as sh.
 
 
Questo in teoria dovrebbe escludere sovrascrizioni della variabile PS1
e ottenere la shell con il valore assegnato da riga di comando.

 e ottenere la shell con il valore assegnato da riga di comando.
 
 
Questo funziona!
E isola il discorso dei files di configurazione della shell:
---------------------------------------------------
default:~$ PS1="pippo:\w$ " bash --noprofile --norc
pippo:~$ exit
exit
default:~$
----------
 
Funziona pur avendo in ~/.bashrc:
 
export PS1="default:\w$ "

 primo messaggio... controllo, se mai specificalo.
 
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
 

 ????
 
C'è poco da capire... Infatti hai riportato correttamente tutto.

                by default if the shell is invoked as sh.
 
Ho provato e sembra che funzioni

Il 27/05/21 16:04, armony ha scritto:

Anche se non funzionano alcune funzioni di autocompletamento.
 
$ type digitoqualcosa MA NON ESCE NIENTE

 tornare allo stato attuale.
 
Attenzione a dare questi suggerimenti
Non è che poi si impalla il sistema (o qualche processo) perchè non 
trova il file?

 In questo modo non dovrebbe funzionare come ci si aspetterebbe.
 
Nel caso e` un errore in .bashrc.
Nel mio c'e` un:
 
if [  "$PS1" ]
then
   do_something
   PS1=...
fi
 
Cioe` se PS1 non e` gia` definito, allora
assegna un valore (facendo prima altre cose).
 
Quindi:
 
PS1="pippo " bash
 
Funziona, perche` salta` la ri-definizione.
 
Non e` codice mio, e` il codice in /etc/bashrc
 
bye,
 
-- 
 
piergiorgio


E cosa dovrebbe uscire invece?
Non ho mica capito i problema...


Tutto può essere...
Ma puoi sempre tornare indietro rinominando il file al suo
nome originario.
 
Non dovrebbe succedere niente se:
- rinomino
- faccio la prova
- rinomino al nome originario
 
Se invece in mezzo fai anche altre operazioni di avvio di altri
programmi o cose così che coinvolgono ".bashrc", o riavvio di
sistema allora potrebbe essere un pelo più verosimile aspettarsi
qualcosa di strano, ma non direi comunque...
 
Vai tranquillo!


Ma errore perché?
Voglio dire, io è anni che ho quella riga in bashrc e non ho notato che
abbia portato a nessun problema.
Chiaro che la richiesta dell'OP è un caso fine a se stesso, diciamo
a scopo didattico, e in quel caso ci sta che si inciampi in un
comportamento inatteso... anzi, direi che ha ancora maggiore valore
sempre didatticamente parlando no?
 
Più che errore diciamo che è una scelta. Gli errori sono altri direi.
Tu mi dirai:
se in /etc/bashrc è scritto così e non cosà...
E io ti dirò:
non ho neanche il file /etc/bashrc ad esempio.
Mettere il costrutto condizionale mi sembra ottimo, soprattutto se dopo
tanto tempo di utilizzo non ti sei accorto che abbia portato a qualche
problema di sorta.
 
La cosa importante è capire come funziona il meccanismo e adottare la
soluzione che ci serve o lasciare quella che c'è se non fa differenza
nella pratica di uso quotidiana.

 nella pratica di uso quotidiana.
 
Questa frase e` meta` corretta.
 
Capire e` importante, ma lasciare un ERRORE
dentro del codice non e` una soluzione valida.
 
Come gia` ripetutamente scritto, ci si espone
a problemi che possono sempre capitare quando
meno lo si aspetta.
E poi si passa un fine settimana, oppure una
settimana, a cercare il problema.
 
In generale, il termine e` "programmazione
difensiva".
 
bye,
 
-- 
 
piergiorgio


Se fosse come scrivi, non esisterebbe ~/.bashrc.
Popolarlo anche con le variabili d'ambiente desiderate è una scelta
consentita proprio perché questi file di configurazione esistono.
Ovviamente come tutte le cose va fatto per uno scopo e con cognizione.
 
Non è detto che proprio grazie alla tua impostazione (non importa che
sia quella copiata da /etc/bashrc della tua distribuzione) tu non possa
incappare in un altro comportamento inatteso, magari confrontandoti con
una situazione come quella del topic corrente, fine a se stessa e dalle
finalità inesistenti.
 
In altre parole se io voglio assicurarmi di lanciare bash in modo che
erediti PS1 definito da riga di comando, posso tranquillamente usare
 
PS1=quellochevoglio bash --norc
 
Qualsiasi sia il ~/.bashrc.
La soluzione corretta formalmente è questa. Anche se poi porta a
perdersi per strada altre personalizzazioni che abbiamo di default,
ma questo è un altro discorso.
 
Definire PS1 come hai tu, va bene, risolve la situazione, ma se io
invece volessi avere sempre PS1 di default? E cercassi proprio di
ottenere la sovrascrittura di qualsiasi valore PS1 definito in altro
modo, allora il tuo bashrc non andrebbe bene. E non perché c'è un
errore nel tuo bashrc, ma perché per mangiare la minestra non puoi
usare la forchetta.
Non ci sono errori, ci sono destinazioni d'uso e soluzioni che
conseguono l'obiettivo.

 conseguono l'obiettivo.
 
La tua *non* e`, per tua stessa ammissione,
una destinazione d'uso e soluzione che
consegue un obiettivo.
Non hai fissato PS1 perche` ti serviva cosi`,
semplicemente non hai pensato alle conseguenze.
 
Definire una variabile di sistema senza controllare
per poi accorgersi che qualcosa non va come dovrebbe
indica un problema.
Soprattutto per il fatto che ti sei accorto *dopo*
del motivo per cui l'assegnazione non funzionava.
 
Il modo *corretto* e` controllare, se non lo fai,
_senza_ ricordartene, hai un errore nel codice.
E siccome dopo un mese nessuno si ricorda piu`,
e` un errore...
 
Ovviamente, uno puo` decidere _coscientemente_
di fissare quella variabile, ma questa e` una
scelta precisa.
 
In tutti gli altri casi vale la regola di controllo,
altrimenti il codice e` sbagliato.
 
Detto altrimenti, nel dubbio si controlla.
Quindi, si, e` un errore in .bashrc, non una
destinazione d'uso diversa.
 
bye,
 
-- 
 
piergiorgio

 destinazione d'uso diversa.
 
Senti, taglio tanto mi pare che quello che avevamo da scrivere
lo abbiamo scritto non serve portarcelo dietro.
Ti propongo qualche esempio in cui se non sbaglio settano PS1
in bashrc:
 
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-shells/bash/files/bashrc
 
https://gist.github.com/jaronson/6893402
 
https://www.macs.hw.ac.uk/~hwloidl/docs/abs-guide/sample-bashrc.html
 
https://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/sample-bashrc.html
 
 
Con questi settaggi, sempre se non sbaglio perché non li ho testati,
si sarebbe incappati nel comportamento rilevato dall'OP e dagli altri
utenti che lo hanno riportato qui.
Può essere che sia sbagliato il bashrc di tutti, oppure può darsi
che quello che stia cercando di fare l'OP sia poco sensato (perché
non aprire una nuova shell e poi settare la variabile PS1 da riga
di comando? Tanto per fare un esempio di alternativa se lo scopo è
osservare il prompt che cambia).
 
Questo, ripeto, non toglie che l'OP abbia proposto un quesito
didatticamente curioso che ha portato a capire meglio cosa va a
leggere bash all'avvio e cosa sovrascrive e come... Ma una cosa è lo
scopo didattico, un'altra è la sensatezza dell'operazione ai fini
pratici. A me sembra che non ce ne sia abbastanza in questo quesito
per gridare all'errore se quell'operazione evidenza un comportamento
apparentemente strano di bash. E questo lo confermano tantissimi
bashrc che settano tranquillamente PS1 senza instruzioni condizionali,
sempre che non abbia io sbagliato a controllarli... In effetti l'ho
fatto abbastanza al volo.

 evidenti, ma magari piu` seri.
 
scusa che sofismo assurdo. se valorizzo una variabile è perché voglio che quella variabile assuma quel valore lì.
se in una sessione interattiva voglio il prompt in un certo modo, perché dovrei testare se non è già stato valorizzato? se uno script di inizializzazione precedente è stato impostato io non lo posso cambiare, secondo te?

 Togli pure quella firma, che in questo contesto, gruppo pubblico, non ha senso.
 
   Ha senso in moltissimi contesti.  Che a *te* non serva è una 
questione tua.
 
 
    Ciao,
 
 
Alessandro
 

Il 27/05/21 16:56, Joe ha scritto:

$ type priority-test # scritto per intero
hash effettuato su priority-test (~/priority/bin/priority-test)
 
$ type priori<TAB>
premendo il tasto TAB dovrebbe essere autocompletato in priority-test
Perchè non funge?

 - rinomino al nome originario
 
ammesso che il si sia già impallato
  inizi a sudare
riavvii il pc e non completa il riavvio
devi cercare la pendrive di ripristino: non la trovi o non c'è l'hai
te la devi scaricare (l'iso) da un altro computer
e serve una pendrive vuota, non c'è l'hai te la devi comprare
è difettosa
te ne compri un'altra
 
E ti è passata una bella giornata per colpa di uno stupido file.
Per cui prudenza prima di dare certi consigli.


Stiamo parlando di .bashrc, non si impalla nulla.
Se il bashrc non c'è bash funziona lo stesso senza problemi di
impallamento del sistema...
Poi se uno ha un bashrc personalizzato che fa cose strane, tali
da coinvolgere addirittura mansioni di sistema (che si presume
richiedano permessi e privilegi sovraordinati all'utente semplice)
allora è perché ci ha messo mano lui stesso e con cognizione di
causa. In quel caso sapresti se toccare o no quel file e probabilmente
non avresti neanche aperto il topic corrente.
 
Ripeto, se togli il bashrc non si impalla nulla di vitale al sistema
operativo.
Diverso il discorso se vai a mettere le mani in files di
inizializzazione del sistema, allora lì il discorso cambia.


Dunque, quello a cui ti riferisci è l'autocompletamento "avanzato" di
bash, che credo anche su ubuntu sia legato ad un pacchetto ausiliario.
In bash di suo c'è l'autocompletamento base... quello dovrebbe
continuare a funzionare regolarmente. Mi riferisco al fatto che se premi
TAB come hai indicato nel tuo esempio, trovandoti nella home "~", allora
TAB produce
 
priority
 
E non priority-test che si trova in una sottocartella.
 
Questo dovrebbe essere funzionante.
 
Invece l'autocompletamente avanzato, viene richiamato da bash attraverso
una chiamata a bash_completion da qualche parte nei suoi file di configurazione.
 
bash_completion è un file di testo con delle istruzioni, niente di che,
e ve ne sono diversi di questi file anche aggiuntivi, puoi aggiungere le,
tue personalizzazioni di autocompletamento ecc ecc va be'.
 
Il punto della tua domanda è:
 
lanciando "bash --norc --noprofile" non ho più l'autocompletamento avanzato.
Certo, è normale, perché salti la lettura di bashrc e dei vari /etc/profile
e altri nella nuova shell.
 
Se guardi il tuo bashrc, in fondo dovresti vedere:
--------------------------------------------------
# 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 ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi
--
 
Quindi hai diverse scelte per ottenere ancora quella funzionalità nella nuova
shell. La più semplice è quella di richiamare la lettura di quel file.
 
. /etc/bash_completion
 
A quel punto se provi:
 
apt[SPAZIO][TAB][TAB]
 
Vedrai saltar fuori una roba tipo:
----------------------------------
autoclean     changelog     download      install       purge         show          upgrade       
autopurge     clean         edit-sources  list          rdepends      showsrc       
autoremove    depends       full-upgrade  moo           remove        source        
build-dep     dist-upgrade  help          policy        search        update
 
 
In alternativa puoi editare il tuo bashrc, andando a ridefinire la variabile
PS1, per esempio impostandola a valore vuoto, o come consigliava Piergiorgio
col costrutto condizionale. A quel punto salvi il file non come bashrc ma come
bashrc.temp.
 
E quando lanci la bash, le dai l'opzione di leggere il file di configurazione
"bashrc-temp":
--------------
 --rcfile file
              Execute commands from file instead of the standard
              personal initialization file ~/.bashrc if the shell is
              interactive (see INVO‐ CATION below).
 
 
quindi:
 
PS1=pippo bash --rcfile ~/bashrc-temp
 
In questo modo preservi il richiamo al bash_completion che si trova nel bashrc-temp
e al contempo imposti PS1 a quello che preferisci.
Come vedi ci sono tante soluzioni, quale scegliere dipende dallo scopo.
 
Se vuoi solo vedere il prompt che cambia:
 
PS1=pippo>[INVIO]
 
Se vuoi farlo in una subshell:
 
bash[INVIO]
PS1=pippo>[INVIO]
 
Se la cosa ti serve per qualcosaltro allora dipende dal qualcosaltro.


dai, non dire fesserie.
il file .bashrc viene invocato solo e soltanto quando avvia bash interattiva, cioè in soldoni quando apri una sessione terminale.
al sistema frega assolutamente nulla di quel file.
e anche per bash è assolutamente opzionale, se non c'è parte uguale solo non avrà le personalizzazioni utente.
 
 

 PS1=pippo bash --rcfile ~/bashrc-temp
 
Viene attivato l'autocompl. ma non viene impostato il prompt personalizzato


PS1=pippo bash --norc
 
testato, funziona.

Il 28/05/21 21:01, rootkit ha scritto:

Non se viene usato in uno script.
 
$ cat test
#!/bin/bash
PS1='pippo\$ ' bash --norc
$ ./test
pippo$ type pri<TAB> # non autocompleta in *priority*
 
 


Ma la soluzione te l'ho già scritta io ieri...
devi usare il comando per attivare l'autocompletamento avanzato
facendo il source del bash_completion.
 
Avviando bash con --norc, salti la lettura del file di configurazione in
cui si trova quella chiamata a bash_completion. E d'altra parte ti
serve --norc, altrimenti bash va a leggere PS1 del file di
configurazione.
 
Bisognerebbe capire il "grande disegno" che sta dietro la tua richiesta.
Se era solo quella del topic la risposta di rootkit basta e avanza e
funziona. L'autocompletamento lo puoi attivare manualmente sul nuovo
prompt come tio scritto nel messagigo di ieri. Problema risolto.
 
Ora però salta invece fuori uno script.
E allora no...
Le tue domande dei giorni scorsi sono mal poste, perché occorre sempre
partire dallo scopo finale. A quel punto forse ti si può consigliare
direttamente una soluzione ottimale e funzionante.
Gli spezzatini di domande come vedi portano a risolvere solo quello che
chiedi, ma senza rispondere (giustamente) a quello che ti saresti
aspettato tu, per fare quello che avevi realmente in mente, senza averlo
spiegato qui.
 
Per cui...
Vuopi fare uno script? (perché in N messaggi di questa discussione non
l'avevi mica specificato...).
Per fare cosa precisamente?


quindi tu vuoi avviare una bash interattiva da un'altra bash interattiva, cambiandogli il prompt e vuoi farlo da dentro uno script.
puoi dare un senso a quello che stai facendo?
risponde ad una esigenza oppure è un puro esercizio fine a se stesso?
 
 

 configurazione.
 
Pardon, hai ragione, quando hai 1000 cose da fare...
 


Prova cosi:
$ echo $SHLVL
$ bash
$ echo $SHLVL
$ bash
 
       SHLVL  È incrementato di uno ogni volta che una istanza di bash viene avviata.
 
basta un semplice export nel file giusto e...
 
export PS1="{$SHLVL} [\u@\h \W]\$ "
 
{1} [michele@syrius ~]$ 
{1} [michele@syrius ~]$ bash
{2} [michele@syrius ~]$ bash
{3} [michele@syrius ~]$ exit
{2} [michele@syrius ~]$ exit
{1} [michele@syrius ~]$ 
 

 volo automaticamente... grazie in anticipo
 
Da me, con Slrn, succede che tutti i caratteri non ascii puro
vengono visualizzati in accordo con questo seguente caso che
riporto dalla manpagina di ascii2uni (opzione: -a I)
 
-cite-
I Generate hexadecimal UTF-8 with each byte's hex preceded by an
  =-sign  (e.g.  =C3=A9) . This is the Quoted Printable format de‐
  fined by RFC 2045.
-/cite-
 
Per evitare cio', mi basta togliere le due righe vuote dagli header
del file di Alessandro (i file delle news li scarico nell'hd con
Slrnpull e poi li leggo da li') ciao
 
Per Alessandro: ne avevamo gia' parlato tempo fa, lo so che i tuoi
mex sono in perfetto accordo con le RFC, ma con Slrn a me non resta
che questa soluzione (perche' lui gli header li vede come terminati
alla prima riga vuota) ciao
(oggi l'ho fatto per il tuo interessante reply sulle pendrive, tolte
le due righe vuote e' diventato perfetto)
 
P.S. Prova anche tu, Joe, a togliere le due righe vuote e vedi cosa
ti fa Tin ariciao
 
-- 
Yoda