avviare nuova sessione bash con prompt modificato

[armony]

~$ PS1='abc$ ' bash
~$

Sembra che la modifica non abbia avuto effetto. Perchè?

[Alessandro Selli]

Il 25/05/21 14:58, armony ha scritto:

> ~$ PS1='abc$ ' bash
> ~$
>
> 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

[Joe]

Alessandro Selli <trap...@route-add.net> wrote:
> [-- multipart/mixed, encoding 7bit, 25 lines --]
>
> [-- text/plain, encoding quoted-printable, charset: iso-8859-15, 18 lines --]

> [-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
> [-- 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

[BIG Umberto]

In date: Wed, 26 May 2021 13:37:42 on group: it.comp.os.linux.iniziare,

Joe wrote:

> 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

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)

[armony]

Il 26/05/21 13:37, Joe ha scritto:

> Alessandro Selli <trap...@route-add.net> wrote:
>> [-- multipart/mixed, encoding 7bit, 25 lines --]
>>
>> [-- text/plain, encoding quoted-printable, charset: iso-8859-15, 18 lines --]
>>
>> Il 25/05/21 14:58, armony ha scritto:
>>> ~$ PS1='abc$ ' bash
>>> ~$
>>>
>>> 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
>>
>>
>> [-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
>> [-- Description: OpenPGP digital signature --]
>
>
>
>
> Aggiungo di provare questo:
>
> ~$ export PS1='abc$ ' bash

Funziona.
Però dato che ci siamo, se puoi dare la spiegazione.

[Alessandro Selli]

Il 26/05/21 13:37, Joe ha scritto:

> Alessandro Selli <trap...@route-add.net> wrote:
>> [-- multipart/mixed, encoding 7bit, 25 lines --]
>>
>> [-- text/plain, encoding quoted-printable, charset: iso-8859-15, 18 lines --]
>>
>> Il 25/05/21 14:58, armony ha scritto:
>>> ~$ PS1='abc$ ' bash
>>> ~$
>>>
>>> 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
>>
>>
>> [-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
>> [-- Description: OpenPGP digital signature --]
>
>
>
> Aggiungo di provare questo:
>
> ~$ 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

[Alessandro Selli]

Il 26/05/21 16:36, armony ha scritto:

> Il 26/05/21 13:37, Joe ha scritto:

>> Aggiungo di provare questo:
>>
>> ~$ export PS1='abc$ ' bash
>
> Funziona.
> 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

[Piergiorgio Sartor]

Da me funziona:

$ PS1="pippo " bash
pippo

Il prompt diventa "pippo ".

Versione bash?

bye,

--

piergiorgio

[rootkit]

Il giorno mercoledì 26 maggio 2021 alle 16:36:47 UTC+2 armony ha scritto:

> > Aggiungo di provare questo:
> >
> > ~$ export PS1='abc$ ' bash
> Funziona.
> 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.

[Piergiorgio Sartor]

On 26/05/2021 20.48, rootkit wrote:
[...]

> 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

[Joe]

BIG Umberto <us...@langnese.nvg.unit.no> wrote:
> In date: Wed, 26 May 2021 13:37:42 on group: it.comp.os.linux.iniziare,
> Joe wrote:
>
>> 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
>
>
> 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.

Non ti chiede cosa vuoi fare con la firma pgp?
A me dà una serie di opzioni, e devo premere il numerino e poi invio...


Ad ogni modo qui ci sono i dettagli della versione che ho installata:

-------------
Version: tin 2.4.5 release 20201224 ("Glen Albyn") Jan 22 2021 01:18:52

Platform:
OS-Name = "linux-gnu"
Compiler:

CC = "gcc"
CFLAGS = "-O2"
CPP = "gcc -E"
CPPFLAGS = "-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=500"
Linker and Libraries:
LD = "gcc"
LDFLAGS = ""
LIBS = "-lncursesw -licuuc"
PCRE = "7.0 18-Dec-2006"
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 -ALLOW_FWS_IN_NEWSGROUPLIST

> [¹]
> 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

Riporto esempio di schermata che mi salta fuori aprendo un messaggio di quel tipo:


=========================================

[-- application/pgp-signature, encoding 7bit, 16 lines, name: OpenPGP_signature --]
[-- Description: OpenPGP digital signature --]

[cut di diversi a capo]


From: Alessandro Selli <trap...@route-add.net> -- Next response --
Subject: Re: avviare nuova sessione bash con prompt modificato
Date: Wed, 26 May 2021 02:31:12 +0200

From: Alessandro Selli <trap...@route-add.net>
Subject: Re: avviare nuova sessione bash con prompt modificato



Il 25/05/21 14:58, armony ha scritto:
> ~$ PS1='abc$ ' bash
> ~$
>

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

[Joe]

Anche da me così non funge:

$ bash --version
GNU bash, versione 4.3.48(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
Licenza GPLv3+: GNU GPL versione 3 o successiva
<http://gnu.org/licenses/gpl.html>

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

[Joe]

Alessandro Selli <trap...@route-add.net> wrote:
> [-- multipart/mixed, encoding 7bit, 27 lines --]
>
> [-- 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!

[Piergiorgio Sartor]

On 26/05/2021 22.30, Joe wrote:
[...]

>> Da me funziona:
>>
>> $ PS1="pippo " bash
>> pippo
>>
>> Il prompt diventa "pippo ".
>>
>> Versione bash?
>>
>> bye,
>
> Anche da me così non funge:
>
> $ bash --version
> 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

[Joe]

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.

[BIG Umberto]

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.

[Yoda]

Addi' 26 mag 2021 14:36:42, armony scrive:

> Il 26/05/21 13:37, Joe ha scritto:

>> Aggiungo di provare questo:
>> ~$ export PS1='abc$ ' bash

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

[BIG Umberto]

In date: Wed, 26 May 2021 19:38:26 on group: it.comp.os.linux.iniziare,

Alessandro Selli wrote:

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

[BIG Umberto]

In date: Wed, 26 May 2021 22:28:12 on group: it.comp.os.linux.iniziare,

Joe wrote:

> 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

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)

[armony]

Il 26/05/21 16:36, armony ha scritto:
>

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

[armony]

Il 26/05/21 22:56, Joe ha scritto:

> Lanciando bash anteposto dall'assegnazione della variabile PS1, il
> prompt assume il nuovo aspetto, "pluto ecc" nell'esempio sopra.

A me no.

> Se non siete in una sessione screen probabilmente non è necessario

Cos'è una sessione screen?

[armony]

Il 26/05/21 21:00, Piergiorgio Sartor ha scritto:

Non funziona: ho provato meglio.

[armony]

Il 26/05/21 19:49, Piergiorgio Sartor ha scritto:

> On 25/05/2021 14.58, armony wrote:
>> ~$ PS1='abc$ ' bash
>> ~$
>>
>> Sembra che la modifica non abbia avuto effetto. Perchè?
>
> Da me funziona:
>
> $ PS1="pippo " bash
> pippo
>
> Il prompt diventa "pippo ".

Ho provato meglio, e in effetti non viene aperta nessuna sub shell

> Versione bash?

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

[Joe]

armony <armony@armony.a> wrote:
> Il 26/05/21 22:56, Joe ha scritto:
>> Lanciando bash anteposto dall'assegnazione della variabile PS1, il
>> prompt assume il nuovo aspetto, "pluto ecc" nell'esempio sopra.
>
> A me no.

Sì ho capito, e anzi ho spiegato che neanche a me funzionava...
Ma hai capito perché non ti funziona?
Ho cercato di spiegarlo ma potrei non essere stato chiaro.

Sostanzialmente nelle impostazioni di "bash" potresti avere
definita la variabile "PS1".

Nel mio caso quell'impostazione era definita a livello dell'utente
locale, nel file:

~/.bashrc

La "tilde" lo sai no?
Sta per "/home/mio_nome_utente".

Si può provare a ricercare il file nella home dove eventualmente la
variabile in questione è assegnata:

grep 'PS1' .* 2>/dev/null |grep -v history

Prova un po' a lanciare quel comando e incollare qui input e output
della riga di comando, anche l'input, che un errore di digitazione
ci può scappare.

Non ricordo che distribuzione stai usando, ma magari lo hai scritto nel
primo messaggio... controllo, se mai specificalo.

>> Se non siete in una sessione screen probabilmente non è necessario
>
> 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.

[Giovanni]

On 05/27/2021 10:36 AM, Joe wrote:
> Sì ho capito, e anzi ho spiegato che neanche a me funzionava...
> Ma hai capito perché non ti funziona?
> Ho cercato di spiegarlo ma potrei non essere stato chiaro.
>
> Sostanzialmente nelle impostazioni di "bash" potresti avere
> 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/ >

[Joe]

BIG Umberto <us...@langnese.nvg.unit.no> wrote:
> In date: Wed, 26 May 2021 22:28:12 on group: it.comp.os.linux.iniziare,
> Joe wrote:
>
>> 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
>
> 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.

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

[Joe]

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.

[Joe]

Joe <J...@e.invalid> wrote:
>
> 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.

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$ "

[armony]

Il 27/05/21 10:36, Joe ha scritto:

> Prova un po' a lanciare quel comando

$ grep 'PS1' .* 2>/dev/null |grep -v history
.bashrc: # ORIGINALE:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
'
.bashrc:
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\[\033[00m\]\[\033[01;34m\]\W\[\033[00m\]\$
'
.bashrc: PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
.bashrc: PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"

> e incollare qui input e output
> della riga di comando, anche l'input, che un errore di digitazione
> ci può scappare.

????

> Non ricordo che distribuzione stai usando, ma magari lo hai scritto nel
> 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

[Joe]

armony <armony@armony.a> wrote:
> Il 27/05/21 10:36, Joe ha scritto:
>> Prova un po' a lanciare quel comando
>
> $ grep 'PS1' .* 2>/dev/null |grep -v history
> .bashrc: # ORIGINALE:
> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
> '
> .bashrc:
> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\[\033[00m\]\[\033[01;34m\]\W\[\033[00m\]\$
> '
> .bashrc: PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
> .bashrc: PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"

Ecco svelato l'arcano.
Come nel mio caso, c'è il ~/.bashrc con dentro PS1 impostato.

Quando tu imposti PS1 da riga di comando, il successivo lancio
di bash eredita quel valore PS1, ma subito dopo questo viene
sovrascritto da bash stessa che va a leggere il .bashrc, e lo
sovrascrive perché appunto lì dentro trova PS1='eccecc'.

Prova a lanciare bash come ho spiegato nell'altro messaggio.
Avevi visto? ( --noprofile --norc )

Oppure prova a rinominare temporaneamente .bashrc in qualcosa
tipo bashrc.bk e rifai la prova, poi rinomini nuovamente per
tornare allo stato attuale.

>> e incollare qui input e output
>> della riga di comando, anche l'input, che un errore di digitazione
>> ci può scappare.
>
> ????

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

[armony]

Il 27/05/21 12:37, Joe ha scritto:

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

Ho provato e sembra che funzioni

[armony]

Il 27/05/21 16:04, armony ha scritto:

Anche se non funzionano alcune funzioni di autocompletamento.

$ type digitoqualcosa MA NON ESCE NIENTE

[armony]

Il 27/05/21 16:00, Joe ha scritto:

> Prova a lanciare bash come ho spiegato nell'altro messaggio.
> Avevi visto? ( --noprofile --norc )

Ho provato e sembra che funzioni, tranne l'auto-completamento.

$ type digito-qualche-iniziale MA NON ESCE NIENTE

> Oppure prova a rinominare temporaneamente .bashrc in qualcosa
> tipo bashrc.bk e rifai la prova, poi rinomini nuovamente per
> tornare allo stato attuale.

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

[Piergiorgio Sartor]

On 26/05/2021 23.15, Joe wrote:
[...]

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

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

[Joe]

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

[Joe]

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!

[Joe]

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.

[Piergiorgio Sartor]

On 27/05/2021 19.10, Joe wrote:
[...]
> Ma errore perché?

Per il semplice fatto che non funziona
quello che hai tentato di fare.

In generale, non solo per questo caso,
prima di _definire_ una variabile andrebbe
controllato che gia` non esista con un
qualche valore assegnato.

> Voglio dire, io è anni che ho quella riga in bashrc e non ho notato che
> abbia portato a nessun problema.

Adesso lo hai notato, pero`.

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

Come scritto sopra, sarebbe buona programmazione
bash evitare di definire variabili (di sistema)
senza prima controllare quale sia lo stato.

PS1 e` praticamente innocua, ma magari ve ne sono
altre che potrebbero portare a problemi meno
evidenti, ma magari piu` seri.

> Più che errore diciamo che è una scelta. Gli errori sono altri direi.

E` un errore, non specifico a questo caso.
E` un errore di concetto, che puo` portare
a conseguenze inaspettate.
Come di fatto e` successo.

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

Questo non c'entra assolutamente niente
con questo discorso.

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

Direi...

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

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

[Joe]

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.

[Piergiorgio Sartor]

On 27/05/2021 21.39, Joe wrote:
[...]

> Se fosse come scrivi, non esisterebbe ~/.bashrc.

Non hai capito niente di quello che ho scritto.

> Popolarlo anche con le variabili d'ambiente desiderate è una scelta
> consentita proprio perché questi file di configurazione esistono.

Ho scritto il contrario?
Che non si deve usare .bashrc per
configurare?

Ho scritto che "prima di cambiare una
variabile (di sistema) va verificato
se esiste ed il contenuto".

Non ho neanche scritto che non si deve
cambiare: si puo` cambiare, ma deve
essere chiaro cosa si stia facendo.

> Ovviamente come tutte le cose va fatto per uno scopo e con cognizione.

Appunto!

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

Questa e` un'affermazione senza senso.

Ridefinire una variabile di sistema senza
preoccuparsi di cosa vi sia e` un rischio.
Fare il contrario non lo e`, perche` si
presuppone che il default sia de-fault.

Il topic corrente non fine a se stesso, e`
valido e si risolve in maniera corretta,
che *non* e` assegnare staticamente PS1
in .bashrc od altrove.

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

No, questa e` la soluzione di chi si ricorda
che in .bashrc tocca quella variabile, oppure
di chi non ha idea di cosa abbia fatto in .bashrc.
Senza contare che in .bashrc potrebbe esservi
altro che serve (ma cosa lo scrivo a fare?) e
quindi non si puo` saltare...

> Definire PS1 come hai tu, va bene, risolve la situazione, ma se io
> invece volessi avere sempre PS1 di default? E cercassi proprio di

Funziona anche i quel caso, che discorsi sono.

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

Questo non ha senso.

Il fatto che PS1 esista come _variabile_ vuol
dire che si puo` cambiare.

Il caso "anomalo" e` bloccare questo cambio,
cioe` renderla una costante, cosa che si puo`
sempre fare, ma e` un caso *anomalo*.
Altrimenti non vi sarebbe una variabile o
sarebbe piu` difficile cambiarla.

> Non ci sono errori, ci sono destinazioni d'uso e soluzioni che
> 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

[Joe]

Piergiorgio Sartor <piergiorgio.sartor.th...@nexgo.removethis.de> wrote:
>
> 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.

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.

[rootkit]

Il giorno giovedì 27 maggio 2021 alle 20:01:03 UTC+2 Piergiorgio Sartor ha scritto:

> Come scritto sopra, sarebbe buona programmazione
> bash evitare di definire variabili (di sistema)
> senza prima controllare quale sia lo stato.
>
> PS1 e` praticamente innocua, ma magari ve ne sono
> altre che potrebbero portare a problemi meno
> 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?

[Alessandro Selli]

Il 27/05/21 05:20, BIG Umberto ha scritto:

> In date: Wed, 26 May 2021 19:38:26 on group: it.comp.os.linux.iniziare,
> Alessandro Selli wrote:
>
>> 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.

Che, essendo pubblica, chiunque può scaricare. Ad esempio da un key
server. O dal mio sito personale. O allegato alle mie email private.
O incluso come intestazione nelle email ecc.

[...]

> Quindi, dove hai depositato la tua chiave pubblica?

Dove chiunque con un minimo di conoscenza del PGP le andrebbe a cercare.

> Ce la puoi fornire personalemnte tramite canali sicuri?

Te la puoi scaricare da solo.

> Ma poi, se non abbiamo bisogno di contattarti privatamente per questioni che
> richiedano una certa sicurezza, cosa ce ne facciamo della tua chiave pubblica?

Questa è la più risibile di tutte.
"Se non ho bisogno di guidare, che me ne faccio della patente?"
"Se non sto male, a che serve che ci sia una farmacia nel quartiere?"

> 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

[armony]

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?

[armony]

Il 27/05/21 18:45, Joe ha scritto:

> Tutto può essere...
> Ma puoi sempre tornare indietro rinominando il file al suo
> nome originario.
>
> Non dovrebbe succedere niente se:
> - rinomino

si impalla il sistema

> - faccio la prova

se il sistema non si è impallato pochi secondi prima può impallarsi adesso

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

[Joe]

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.

[Joe]

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.

[rootkit]

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.

[armony]

Il 28/05/21 13:44, Joe ha scritto:
> PS1=pippo bash --rcfile ~/bashrc-temp

Viene attivato l'autocompl. ma non viene impostato il prompt personalizzato

[rootkit]

PS1=pippo bash --norc

testato, funziona.

[armony]

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*

[Joe]

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?

[rootkit]

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?

[armony]

Il 29/05/21 10:33, Joe ha scritto:

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

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

[Mario M. Macaluso]

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 ~]$

[Yoda]

Addi' 26 mag 2021 11:37:42, Joe scrive:
> Alessandro Selli <trap...@route-add.net> wrote:

>> [-- multipart/mixed, encoding 7bit, 25 lines --]

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

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