[SOLVED] Re: variables in bash
Hi, thank you all for the fast response. It helped a lot and made everything clear. The problem is solved. Have a nice eastern. Best Hans
Re: variables in bash
On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote: > Hi folks, > > just an easy question: > > What is the difference (if any) between the following two variables in a > shellfile in bash: > > 1. mypath=/home/user1/Tools/ Here you are assigning a value to the variable "mypath". You can surround "/home/user1/Tools" with quotes if you like, but it is not strictly necessary. > > and $mypath Here you are actually *using* the variable "mypath". Here is another example: NAME="paulf" echo "My name is $NAME." which will yield: My name is paulf. -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
Re: variables in bash
On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote: > What is the difference (if any) between the following two variables in a > shellfile in bash: > > 1. mypath=/home/user1/Tools/ > 2. mypath="/home/user1/Tools/" They are the same. The quotes are optional here, because your assignment doesn't contain any whitespace. The quotes would be required if you had something like: mypath="/mnt/c/Program Files/" In any case, the assignment is the easy part. Most people get this part right. Where they screw up is here: > and $mypath Whenever[1] you use "$mypath", you'll want double quotes around it. Otherwise, it'll get split into multiple words at whitespace, and will also be subject to filename expansion. You don't want that. mypath="/mnt/c/Program Files/" if ! test -d $mypath; then ... # wrong The example above will *not* work, because the space in the middle of $mypath's value will cause the test command to receive two separate words, instead of one word. It needs to be quoted: mypath="/mnt/c/Program Files/" if ! test -d "$mypath"; then ...# right > Is this in bash the same? Do other shells (sh, zsh, whatever) handle these > two > different? Most quoting rules are the same in all sh-derived shells, including the rules I talked about here. As you dive deeper into shell scripting, you'll find some cases where the rules change a bit across different shells, but so far you're still in the shallow end. [1] There are some exceptions, but for now, go with the simplest rule: "When in doubt, double-quote it."
variables in bash
Hi folks, just an easy question: What is the difference (if any) between the following two variables in a shellfile in bash: 1. mypath=/home/user1/Tools/ and $mypath or 2. mypath="/home/user1/Tools/" and $mypath Is this in bash the same? Do other shells (sh, zsh, whatever) handle these two different? Thanks for any answer, can be short! Best regards Hans
Re: bash parameter expansion "doesn't like" dots?
On Tue, 5 Mar 2024 at 02:59, Greg Wooledge wrote: We might *guess* that this change was made to make dash more strict about POSIX minimalism (removing extensions), but without documentation we can't do more than guess about motives. The motivation is to avoid difference in behavior when compiled with internal fnmatch implementation and with glibc https://lore.kernel.org/dash/e341e41f-8c32-b6e4-8be3-8f94fae26...@gigawatt.nl/ Re: possible wrong behaviour with patterns using a quoted ^ at the start of a bracket expression. Wed, 12 Jan 2022 17:20:54 + This bug (you're right that it's a bug) is specific to builds that use fnmatch(). In dash itself, ^ is always assumed as a literal. In builds with --disable-fnmatch you get correct results. On 05/03/2024 12:22, David wrote: A bit more info: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028002 Unfortunately this bug has been left without a response from the maintainer. The release notes mentions the issue: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#dash-circumflex https://bugs.debian.org/1034344
Re: bash parameter expansion "doesn't like" dots?
On Tue, 5 Mar 2024 at 02:59, Greg Wooledge wrote: > On Tue, Mar 05, 2024 at 11:24:11AM +0900, John Crawley wrote: > > ^ worked as a negator in dash character classes up to Bullseye though, so > > something has changed recently. That's what my web searching failed to > > find... > > It looks like dash doesn't have up-to-date documentation on its changes. > There's a ChangeLog file in the upstream Git repository's top level > directory[1] (shipped as changelog.gz in the Debian package), but the most > recent entry in it is dated 2014-11-17. > > We might *guess* that this change was made to make dash more strict > about POSIX minimalism (removing extensions), but without documentation > we can't do more than guess about motives. > > [1] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/ A bit more info: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028002 Previous discussion on debian-user: https://lists.debian.org/debian-user/2023/04/msg00559.html
Re: bash parameter expansion "doesn't like" dots?
On Tue, Mar 05, 2024 at 11:24:11AM +0900, John Crawley wrote: > ^ worked as a negator in dash character classes up to Bullseye though, so > something has changed recently. That's what my web searching failed to find... It looks like dash doesn't have up-to-date documentation on its changes. There's a ChangeLog file in the upstream Git repository's top level directory[1] (shipped as changelog.gz in the Debian package), but the most recent entry in it is dated 2014-11-17. We might *guess* that this change was made to make dash more strict about POSIX minimalism (removing extensions), but without documentation we can't do more than guess about motives. [1] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/
Re: bash parameter expansion "doesn't like" dots?
On 05/03/2024 11:36, Max Nikulin wrote: On 05/03/2024 09:02, Greg Wooledge wrote: On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote: I think ^ has been deprecated recently. I failed to find a reference on the web just now though. So, ^ isn't "deprecated". It's just not portable to sh. Running shellcheck on a *sh* script with a [^s] glob gives https://www.shellcheck.net/wiki/SC3026 "In POSIX sh, ^ in place of ! in glob bracket expressions is undefined." with some links. There is no warning in the case of a #!/bin/bash script. Thanks! Shellcheck also says: "Dash used to support [^c] when compiled with fnmatch and glob from glibc, but it was considered as a bug and fixed in version 0.5.12." That's the version of dash which arrived in Debian Bookworm. -- John
Re: bash parameter expansion "doesn't like" dots?
On 05/03/2024 09:02, Greg Wooledge wrote: On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote: I think ^ has been deprecated recently. I failed to find a reference on the web just now though. So, ^ isn't "deprecated". It's just not portable to sh. Running shellcheck on a *sh* script with a [^s] glob gives https://www.shellcheck.net/wiki/SC3026 "In POSIX sh, ^ in place of ! in glob bracket expressions is undefined." with some links. There is no warning in the case of a #!/bin/bash script.
Re: bash parameter expansion "doesn't like" dots?
On 05/03/2024 11:02, Greg Wooledge wrote: On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote: On 05/03/2024 05:27, David Wright wrote: Which shell also matters. The OP appears to be using ^ to negate, but ! has the advantage that it will be understood in bash and dash. I think ^ has been deprecated recently. I failed to find a reference on the web just now though. POSIX specifies that ! is the negation character in glob ranges, largely because ^ used to be a synonym for | in the old Bourne shell (for the benefit of keyboards that didn't have a convenient | character). The use of ^ as a glob negation is a bash extension. It's nice for people who may not even realize that they're supposed to be using ! because they learned regular expressions first. So, ^ isn't "deprecated". It's just not portable to sh. ^ worked as a negator in dash character classes up to Bullseye though, so something has changed recently. That's what my web searching failed to find... -- John
Re: bash parameter expansion "doesn't like" dots?
On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote: > On 05/03/2024 05:27, David Wright wrote: > > Which shell also matters. The OP appears to be using ^ to negate, > > but ! has the advantage that it will be understood in bash and dash. > > I think ^ has been deprecated recently. I failed to find a reference on the > web just now though. POSIX specifies that ! is the negation character in glob ranges, largely because ^ used to be a synonym for | in the old Bourne shell (for the benefit of keyboards that didn't have a convenient | character). The use of ^ as a glob negation is a bash extension. It's nice for people who may not even realize that they're supposed to be using ! because they learned regular expressions first. So, ^ isn't "deprecated". It's just not portable to sh.
Re: bash parameter expansion "doesn't like" dots?
On 05/03/2024 05:27, David Wright wrote:
Pattern matching in the shell is not the same as in grep: the
rules are different, but similar enough to confuse.
Grep uses regular expressions, while the shell is usually globs. (I have no
experience of shells other than dash and bash though.)
Bash can compare with regexes using the =~ operator [[ $A =~ $B ]] ...
Which shell also matters. The OP appears to be using ^ to negate,
but ! has the advantage that it will be understood in bash and dash.
I think ^ has been deprecated recently. I failed to find a reference on the web
just now though.
Testing with dash on Bullseye:
$ v=string
$ echo ${v#*[!s]}
ring
$ echo ${v#*[^s]}
ring
But on Bookworm:
$ v=string
$ echo ${v#*[!s]}
ring
$ echo ${v#*[^s]}
tring
Now the ^ is being treated as just a list member.
With Bash the ^ still seems to be treated as a negator on Bookworm.
So yes, we should be switching to !
--
John
Re: bash parameter expansion "doesn't like" dots?
On Mon 04 Mar 2024 at 11:51:29 (+0900), John Crawley wrote:
> On 04/03/2024 10:07, David Wright wrote:
> > On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
> > > bash doesn't seem to like dots too close to brackets:
> > >
> > > echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
> > >
> > > works fine.
> > >
> > > On 3/3/24, Albretch Mueller wrote:
> > > > _VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
> > > >
> > > > echo "${_VAR//[^a-zA-Z0-9_-]/}"
> > > >
> > > > echo "${_VAR//[^a-zA-Z0-9_-.]/}"
> > ↑↑↑
> >
> > That's a range, except that it isn't because it's written backwards.
> > Check for yourself by testing with 9-0 instead of 0-9.
> >
> So the problem isn't about dots,
It shouldn't be, as there's nothing special about ".", though there's
the mystery of what was said in the OP's quoted post, which we're not
privy to.
> but the handling of the - which has to go last if it isn't to be treated as a
> range marker.
First or last in the set. I prefer last, because "]" can only go first
in the set to be a matchable character.
> https://www.gnu.org/software/grep/manual/html_node/Character-Classes-and-Bracket-Expressions.html
> says:
>
> ‘-’
> represents the range if it’s not first or last in a list or the ending
> point of a range. To make the ‘-’ a list item, it is best to put it last.
Well, here's a clue as to where the trouble might have arisen.
Pattern matching in the shell is not the same as in grep: the
rules are different, but similar enough to confuse.
Which shell also matters. The OP appears to be using ^ to negate,
but ! has the advantage that it will be understood in bash and dash.
Cheers,
David.
Re: bash parameter expansion "doesn't like" dots?
On 04/03/2024 10:07, David Wright wrote:
On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
bash doesn't seem to like dots too close to brackets:
echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
works fine.
On 3/3/24, Albretch Mueller wrote:
_VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
echo "${_VAR//[^a-zA-Z0-9_-]/}"
echo "${_VAR//[^a-zA-Z0-9_-.]/}"
↑↑↑
That's a range, except that it isn't because it's written backwards.
Check for yourself by testing with 9-0 instead of 0-9.
Cheers,
David.
So the problem isn't about dots, but the handling of the - which has to go last
if it isn't to be treated as a range marker.
https://www.gnu.org/software/grep/manual/html_node/Character-Classes-and-Bracket-Expressions.html
says:
‘-’
represents the range if it’s not first or last in a list or the ending
point of a range. To make the ‘-’ a list item, it is best to put it last.
--
John
Re: bash parameter expansion "doesn't like" dots?
On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
> bash doesn't seem to like dots too close to brackets:
>
> echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
>
> works fine.
>
> On 3/3/24, Albretch Mueller wrote:
> > _VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
> >
> > echo "${_VAR//[^a-zA-Z0-9_-]/}"
> >
> > echo "${_VAR//[^a-zA-Z0-9_-.]/}"
↑↑↑
That's a range, except that it isn't because it's written backwards.
Check for yourself by testing with 9-0 instead of 0-9.
Cheers,
David.
Re: bash parameter expansion "doesn't like" dots?
bash doesn't seem to like dots too close to brackets:
echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
works fine.
lbrtchx
On 3/3/24, Albretch Mueller wrote:
> _VAR="admissions.piedmont.edu_files?trackid=wnm:1980=what-is-the-second-fundamental-theorem-of-calculus(1).pdf"
>
> echo "${_VAR//[^a-zA-Z0-9_-]/}"
>
> echo "${_VAR//[^a-zA-Z0-9_-.]/}"
>
[HS] assistance au code (Re: Script BASH gestion des espaces des noms de fichier)
Bonjour, Le 2024-02-05 16:07, Daniel Caillibaud a écrit : Oui, et je vous encourage à passer vos shell bash à shellcheck, il signale ce genre d'erreur (et plein d'autres). Il est parfois un peut trop zélé, mais on peut lui dire qu'on sait ce qu'on fait avec du # shellcheck disable=SC avant la ligne qui le fait râler (où est le code d'erreur qu'il signale) Avec Neovim, on peut avoir ce genre d'assistance en direct :) Sébastien
Re: Script BASH gestion des espaces des noms de fichier
Le 02/02/24 à 08:54, Jérémy Prego a écrit : > Pour éviter ce problème, on peut mettre les variables entre " > > du coup, ça donnerai: > > pdftk "$fichier1" stamp "$tampon" output "$fichier2" Oui, et je vous encourage à passer vos shell bash à shellcheck, il signale ce genre d'erreur (et plein d'autres). Il est parfois un peut trop zélé, mais on peut lui dire qu'on sait ce qu'on fait avec du # shellcheck disable=SC avant la ligne qui le fait râler (où est le code d'erreur qu'il signale) -- Daniel La pensée vole et les mots vont à pied. Voilà tout le drame de l'écrivain. Julien Green
Re: Script BASH gestion des espaces des noms de fichier
Essaie des cotes dans tes attributions de noms.
Par exemple :
TOTO="${NomFic}"
avec
NomFic="Mon Fichier"
Pareillement cote les appels :
Cmd —variable "${NomFic}"
Par exemple. Le fait de coter l’appel de variable avec des double cote permet à
BASH de considérer NomFic comme un seul paramètre envoyé à Cmd avec ses blancs.
Après il faut savoir comment la commande Cmd va traiter tout ça…
> Le 2 févr. 2024 à 07:51, Informatique BILLARD
> a écrit :
>
> Bonjour
>
> j'ai écrit un petit script qui lance à la fin cette commande :
>
> pdftk $fichier1 stamp $tampon output $fichier2
>
> avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres
> fournis au script .
>
> Mais je rencontre un problème quand il y a un espace dans le nom de fichier
> ou le répertoire pour pdftk ces espaces engendrent une erreur.
>
> J'ai pourtant placé l'antislah avant mes espace dans l'affectation des
> variables.
>
> tampon=/user/Document/cachet\ pdf
>
> Merci par avance
>
> François-Marie
>
--
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France
« SPAM : Spieced Pork and Meat »
Pierre Dac (Londres, 1944)
Extrait de « Pierre DAC parle au Français » sur Radio Londres, le 24 mars 1944,
dans Drôle de guerre, éditions Omnibus (2008), pages 93 à 96.
(https://www.epi.asso.fr/revue/articles/a1602d.htm)
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Re: Script BASH gestion des espaces des noms de fichier
Effectivement François Merci d'avoir rectifié. Erwann Le 02/02/2024 à 13:09, François TOURDE a écrit : Le 19755ième jour après Epoch, Erwann Le Bras écrivait: Éviter les boucles "for" avec listes de fichiers (for f in `ls "$dir"`) ou (for f in *), les espaces sont mal interprétés. Ça marche très bien l'utilisation avec for f in *, si tu prends soin d'utiliser "$f" plutôt que juste $f Par contre, le "in `ls *`" n'est effectivement pas une bonne idée.
Re: Script BASH gestion des espaces des noms de fichier
Le 19755ième jour après Epoch, Erwann Le Bras écrivait: > Éviter les boucles "for" avec listes de fichiers (for f in `ls > "$dir"`) ou (for f in *), les espaces sont mal interprétés. Ça marche très bien l'utilisation avec for f in *, si tu prends soin d'utiliser "$f" plutôt que juste $f Par contre, le "in `ls *`" n'est effectivement pas une bonne idée.
Re: Script BASH gestion des espaces des noms de fichier
bonjour
comme dis par ailleurs, pas de problème avec les espaces si les
variables et chemins sont bien protégés avec des doubles-cotes (["])
fichier="mon fichier"
dir="$HOME/mon répertoire"
cp "$fichier" "$dir"
Éviter les boucles "for" avec listes de fichiers (for f in `ls "$dir"`)
ou (for f in *), les espaces sont mal interprétés.
À la place utiliser "find" : find "$dir" -name "${fichier}*" -exec
c'est à peu près tout.
Erwann
Le 02/02/2024 à 08:41, Informatique BILLARD a écrit :
Bonjour
j'ai écrit un petit script qui lance à la fin cette commande :
pdftk $fichier1 stamp $tampon output $fichier2
avec $fichier1 et $tampon, $fichier2 sont construit à partir des
paramètres fournis au script .
Mais je rencontre un problème quand il y a un espace dans le nom de
fichier ou le répertoire pour pdftk ces espaces engendrent une erreur.
J'ai pourtant placé l’antislash avant mes espace dans l'affectation
des variables.
tampon=/user/Document/cachet*\ *pdf
Merci par avance
François-Marie
Re: Script BASH gestion des espaces des noms de fichier
merci je ne connaissais pas cet outils François-Marie Le 02/02/2024 à 09:54, Klaus Becker a écrit : Detox est ton ami Klaus
Re: Script BASH gestion des espaces des noms de fichier
Bon j'ai tourné le problème dans tous les sens et finalement j'ai opté pour ceci 1. le nom du fichier passé comme argument au script est traité pour remplacer les espaces par des underscore. 2. je fait un renommage de ce fichier avec le nom sans espaces. 3. Puis traitement et tout fonctionne. Merci à vous. François-Marie Le 02/02/2024 à 08:57, Cyrille a écrit : Bjr, tampon=/user/Document/cachet\ pdf et tampon="/user/Document/cachet\ pdf" (utiliser des double quote ?? ++
Re: Script BASH gestion des espaces des noms de fichier
Detox est ton ami Klaus
Re: Script BASH gestion des espaces des noms de fichier
Le 02/02/2024 à 08:48, Basile Starynkevitch a écrit : On 2/2/24 08:41, Informatique BILLARD wrote: Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Une solution simple c'est de s'interdire les espaces dans les noms de fichiers. Pourquoi ne pas coder par exemple Oui en effet j'ai fini par supprimer les espaces dans les noms de fichiers et répertoires. Cependant ce script traite des fichiers ayant parfois des espaces et si je dois renommer à chaque fois je vais perdre l'intérêt du script. tampon=/user/Document/cachet.pdf et ensuite lancer votre script avec /bin/bash -vx lescriptbash Merci par avance François-Marie
Script BASH gestion des espaces des noms de fichier
Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l'antislah avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie
Re: Script BASH gestion des espaces des noms de fichier
Bjr, > tampon=/user/Document/cachet\ pdf et tampon="/user/Document/cachet\ pdf" (utiliser des double quote ?? ++
Re: Script BASH gestion des espaces des noms de fichier
bonjour, Le 02/02/2024 à 08:41, Informatique BILLARD a écrit : Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 Pour éviter ce problème, on peut mettre les variables entre " du coup, ça donnerai: pdftk "$fichier1" stamp "$tampon" output "$fichier2" avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie Jerem
Re: Script BASH gestion des espaces des noms de fichier
On 2/2/24 08:41, Informatique BILLARD wrote: Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Une solution simple c'est de s'interdire les espaces dans les noms de fichiers. Pourquoi ne pas coder par exemple tampon=/user/Document/cachet.pdf et ensuite lancer votre script avec /bin/bash -vx lescriptbash Merci par avance François-Marie -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir: https://github.com/RefPerSys/RefPerSys
Script BASH gestion des espaces des noms de fichier
Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie
Re: exemple en GNU bash de variable tableau
Bonsoir Basile,
Basile Starynkevitch, on 2024-01-29:
> J'essaie de collecter dans une variable tableau de bash files_to_remove les
> fichiers temporaires (qu'il faudrait suprimer à la fin de cez script).
>
> Je n'arrive pas à comprendre la syntaxe des variables tableau en GNU bash.
Comme le veut l'adage, un exemple clair vaut mieux que des
mégaoctets de documentation. Pour initialiser les entrées d'un
tableau, on peut faire comme ceci :
$ TAB[0]='zero'
$ TAB[1]='un'
$ TAB[2]='deux'
Et pour accéder aux valeurs, il faut impérativement entourer la
variable avec l'index d'accolades, comme suit :
$ echo "${TAB[0]}"
zero
$ echo "${TAB[1]}"
un
$ echo "${TAB[2]}"
deux
Il y a deux méthodes bien distinctes pour accéder à tous les
éléments d'un coup, via l'astérisque ou l'arobaze, illustrées
par l'exemple ci-dessous :
$ for elem in "${TAB[*]}"; do echo " * $elem"; done
* zero un deux
$ for elem in "${TAB[@]}"; do echo " * $elem"; done
* zero
* un
* deux
À noter que dans ce genre de situations, il devient essentiel
d'être clair sur l'usage systématique des double quotes.
Une construction courante pour accéder aux éléments à partir de
l'index, comme celà arrive fréquemment en langages compilés
impératifs, peut ressembler à ça :
$ for i in $(seq 0 2) ; do echo " $i. ${TAB[$i]}"; done
0. zero
1. un
2. deux
Il est aussi possible de construire et de concaténer des
tableaux avec l'opérateur "parenthèse", par exemple :
$ TAB=( "${TAB[@]}" "trois" "quatre" )
$ for elem in "${TAB[@]}"; do echo " * $elem"; done
* zero
* un
* deux
* trois
* quatre
Là encore, l'usage de l'arobase et des double quotes est
essentiel pour que la concaténation se passe comme attendu :
$ TAB_SUITE=( "le cinquieme" "le sixieme" )
$ TAB_INATTENDU=( "${TAB[*]}" ${TAB_SUITE[@]} )
$ for elem in "${TAB_INATTENDU[@]}" ; do echo " * $elem" ; done
* zero un deux trois quatre
* le
* cinquieme
* le
* sixieme
$ TAB_ATTENDU=( "${TAB[@]}" "${TAB_SUITE[@]}" )
$ for elem in "${TAB_ATTENDU[@]}" ; do echo " * $elem" ; done
* zero
* un
* deux
* trois
* quatre
* le cinquieme
* le sixieme
La documentation de référence sur les tableaux du bash se trouve
dans le manuel de bash(1) au chapitre "Array", qui peut être
retrouvé en effectuant une recherche de l'expression rationnelle
"^ Arrays".
Bonne soirée, :)
--
.''`. Étienne Mollier
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/5, please excuse my verbosity
`-on air: Life Line Project - Unica
signature.asc
Description: PGP signature
Re: exemple en GNU bash de variable tableau
On 1/29/24 16:48, Michel Verdier wrote: Le 29 janvier 2024 Basile Starynkevitch a écrit : J'essaie de collecter dans une variable tableau de bash files_to_remove les fichiers temporaires (qu'il faudrait suprimer à la fin de cez script). Pourquoi un tableau ? Une simple liste ne suffit pas ? Bien sûr que si, pour le script https://github.com/RefPerSys/RefPerSys/blob/master/do-configure-refpersys.bash (le script de configuration du moteur d'inférences libre RefPerSys en http://refpersys.org/ ) *Une liste simplement chainée mais _mutable_ conviendrait tout à fait.* La question plus technique devient: *comment implémente-t-on* (en quelques lignes de GNU bash sous Linux) *une telle liste simplement chainée*. Pour rappel: C++ a des listes simplement chainées (pour les détails consulter https://en.cppreference.com/w/cpp/container/list ...) et Ocaml a des listes simplement chainées (pour les détails consulter https://v2.ocaml.org/api/List.html ) et Guile ou Scheme a des listes simplement chainées (voir la section 6.3.2 du R5RS <https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/>) Un exemple en GNU bash (testable sous Linux) de liste simplement chainée me convient. L'exemple https://www.unix.com/shell-programming-and-scripting/271790-implementing-linked-list-shell-scripting.html me parait trop long. Je souhaite un exemple bien plus simple, ou bien la suggestion de passer de GNU bash à autre chose (je songe peut-être à Python, que je ne connais guère). Pour les aspects "philosophiques" de RefPerSys n'hésitez pas à consulter https://afia.asso.fr/journee-hommage-j-pitrat/ Pour un brouillon de papier en anglais (ou même un brouillon très incomplet en français), me contacter par courriel Librement. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ Seehttps://github.com/RefPerSys/RefPerSys
Re: exemple en GNU bash de variable tableau
Le 29 janvier 2024 Basile Starynkevitch a écrit : > J'essaie de collecter dans une variable tableau de bash files_to_remove les > fichiers temporaires (qu'il faudrait suprimer à la fin de cez script). Pourquoi un tableau ? Une simple liste ne suffit pas ?
Re: exemple en GNU bash de variable tableau
Bonjour Suis certainement à côté de la plaque, mais l'instruction "trap" pourrait peut être faire l'affaire? On 29/01/2024 12:42, didier gaumet wrote: Bonjour, Avertissement: j'ai jamais vraiment écrit quoi que ce soit en Bash donc ne pas se fier aveuglément à mes paroles De ce que je comprends, Bash ne gère pas nativement les tableaux multi-dimensions (cf la doc Bash): https://www.gnu.org/software/bash/manual/html_node/Arrays.html il faut donc contourner cette limitation. Un exemple ici: https://unix.stackexchange.com/questions/611813/how-to-implement-2d-matrix-using-shell-script
Re: exemple en GNU bash de variable tableau
Bonjour, Avertissement: j'ai jamais vraiment écrit quoi que ce soit en Bash donc ne pas se fier aveuglément à mes paroles De ce que je comprends, Bash ne gère pas nativement les tableaux multi-dimensions (cf la doc Bash): https://www.gnu.org/software/bash/manual/html_node/Arrays.html il faut donc contourner cette limitation. Un exemple ici: https://unix.stackexchange.com/questions/611813/how-to-implement-2d-matrix-using-shell-script
exemple en GNU bash de variable tableau
Bonjour la liste Dans https://github.com/RefPerSys/RefPerSys (un projet de moteur d'inférences sous licence GPLv3+ pour Debian) j'essaie de coder un script en bash de configuration (simple). Voir le commit bfb1314 du fichier do-configure-refpersys.bash (les commentaires sont en mauvais englais) J'essaie de collecter dans une variable tableau de bash files_to_remove les fichiers temporaires (qu'il faudrait suprimer à la fin de cez script). Je n'arrive pas à comprendre la syntaxe des variables tableau en GNU bash. Pour info, mon ordinateur est x86-64 sous Debian/Trixie mis à jour ce matin. Avec GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu) Merci de vos eclairages, ou bien d'un exemple (moins de cent lignes de GNU bash) qui utilise une variable tableau en y ajouter (dans une itération) des éléments (ici des noms de fichiers à supprimer plus tard) Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See https://github.com/RefPerSys/RefPerSys
Le bash et le zhc ?
Slt, Bon je commence la formation : https://www-eni-training-com.bnf.idm.oclc.org/portal/client/video/home Scripting sous Linux Et donc comme au Cnit la Défense un Debiantiste, dont j'ai peut-etre encore les cd, m'a dit laisse tomber RedHat, vient chez les vrai Oui oui il a dit des choses plus violentes, mais je menage tous le monde ! Et donc quelqu'un a ses support de cours de Jussieu ou de Diderot a me donner ? Quelqu'un veut la suivre avec moi ? Ou le monde obscure a envahie le lieu ? Merci -- Ptilou J'ai pas d'affichage sous Chrome ? Tu as peur que je sache pecher ?
Re: single quote "'" in bash xterm or lxterminal
On Sun 31 Dec 2023 at 00:43:40 (-0600), Mike McClain wrote: > I > suspect logging into a system where you have no home for your primary > user might get interesting. That problem is simple to resolve. I have encrypted /home partitions on all my systems, but the root filesystem has a /home/primaryUser containing the /etc/skel/* files, in case I should login before remembering to unock/mount the real /home. (The uncoloured default prompt makes the mistake obvious.) What struck me as odd about your narrative was that you place a configuration file under /mc rather than in the company of your dotfiles under /home. Cheers, David.
Re: single quote "'" in bash xterm or lxterminal
Mr. Wooledge, Long before I realized I could put /home/mike on a separate partition I started putting my stuff on a separate partition and just called it /mc. A couple of tomes I had different OS versions on the same hard drive so it made sense to keep the portions of my stuff that weren't OS specific in a place I could reach from both OS installs. Since my tower died and I replaced it with a Raspberry PI, home is on the uSD. Having /mc on a flash drive means I have it available whether I'm running debian, devuan or raspbian and if home were on that flash since those OSs are only similar things could get even more confusing than they are with my setup. A problem I've not run into but considered is how to deal with thngs if that flash drive dies. I suspect logging into a system where you have no home for your primary user might get interesting. Mr. Nikulin, I shouldn't be surprised if xterm-256color is just enough different from xterm and lxterminal that that is why you don't see a problem with the '"...": ...' syntax. If you have xterm-256color you likely have xterm too. Have you tried it? Thanks for showing me different ways of looking at my challenges. Happy New Year fellas Mike -- Happiness is not so much in having but in sharing.
Re: single quote "'" in bash xterm or lxterminal
On 30/12/2023 09:14, Mike McClain wrote: Since some of these use a spinoff of xterm [ -n $DISPLAY ] is a little more generic than [ $TERM == xterm ], RaspberryPI has chosen lxterminal as their default which would would fail that test but still runs bash. I would expect that the reason of failure is echo $TERM xterm-256color so in bash the test should be e.g. [[ "$TERM" == xterm* ]]. The issue with $DISPLAY test is that you may start screen or tmux in xterm or lxterminal. I am unsure if keys generate the same escape sequences for these terminal types. Conditions in inputrc files are a bit more intelligent in respect to terminal types, see readline(3): Conditional Constructs term The term= form may be used to include terminal-specific key bindings, perhaps to bind the key sequences output by the terminal's function keys. The word on the right side of the = is tested against the full name of the terminal and the portion of the terminal name before the first -. This allows sun to match both sun and sun-cmd, for instance. P.S. I have not managed to reproduce the single quote issue bind -f /tmp/input-binding cat /tmp/input-binding '"\M-[1;5H": backward-kill-line' bind -p | grep backward-kill-line "\C-x\C-?": backward-kill-line If I strip single quotes then another binding is added successfully.
Re: single quote "'" in bash xterm or lxterminal
On Fri, Dec 29, 2023 at 08:14:37PM -0600, Mike McClain wrote: > As it turns out every line in /mc/bin/xterm_bindings that > was not a comment was problematic.From man readline or info readline > I saw this: bind '"\C-x\C-r": re-read-init-file' and that is the syntax > I used in xterm_bindings, as '"\e[1;5H": backward-kill-line'. Yeah, that's incorrect syntax. You're dealing with two separate kinds of things: bind commands issued by a shell, and readline key bindings read from a file. When you put a readline key binding into a file like ~/.inputrc or like your /mc/bin/xterm_bindings file, it looks like this: "keys": action But when you do the same thing with bash's bind command, you need to wrap a *second* layer of quotes around it, like this: bind '"keys": action' The outer layer of quotes is removed by the shell, leaving the readline binding (which includes literal double-quotes) as a single argument. You've mixed up the two syntaxes. That's the source of the problem. > You wondered what /mc/implied, my name is McClain so /mc is where my > stuff goes to separate it from system stuff making it easier to move > my stuff from distribution to distribution. That's what your home directory is for, though. It seems odd to keep personal settings in two separate locations like this.
Re: single quote "'" in bash xterm or lxterminal
In response to Greg Wooledge's message of Wed, 27 Dec. As it turns out every line in /mc/bin/xterm_bindings that was not a comment was problematic.From man readline or info readline I saw this: bind '"\C-x\C-r": re-read-init-file' and that is the syntax I used in xterm_bindings, as '"\e[1;5H": backward-kill-line'. Looking as you suggested for the problematic line, I deleted each line until none were left, only then did the "'" problem go away. When I compared .inputrc to xterm_bindings I then saw the problem. You wondered what /mc/implied, my name is McClain so /mc is where my stuff goes to separate it from system stuff making it easier to move my stuff from distribution to distribution. I started with DosLinux back around 1997-8 and have used redhat, slakware, solaris, freebsd and settled on Debian early this century. Since some of these use a spinoff of xterm [ -n $DISPLAY ] is a little more generic than [ $TERM == xterm ], RaspberryPI has chosen lxterminal as their default which would would fail that test but still runs bash. In spite of having used linux for years I'm still a 'luser' compared to you and often fumble as this case demonstrates. I do appreciate your input, bothe here and on the bash list. Thanks for the help and I wish you a happy new year. Mike -- Happiness is not so much in having but in sharing.
Re: single quote "'" in bash xterm or lxterminal
On Thu, Dec 28, 2023 at 09:15:52AM +0700, Max Nikulin wrote: > On 26/12/2023 23:57, Mike McClain wrote: > > Only when xterm_bindings has no executable lines in it does it not > > kill '"' in an X terminal window. > > The line that pulled it in was ; > > [ -n "$DISPLAY" ] && [ -f /mc/bin/xterm_bindings ] && bind -f > > /mc/bin/xterm_bindings; > > I do not see anything that may cause the issue with single quote in the > following message. I am curious what was the goal of the particular binding > that had so detrimental side effect. > > https://lists.debian.org/msgid-search/20110218064727.GA6305@playground > Re: xterm question [SOLVED] Thu, 17 Feb 2011 22:47:27 -0800 That message is over 12 years old. It's quite likely some changes have been made since then. I'd also be curious to see which line of the /mc/bin/xterm_bindings file actually caused the issue. I'm guessing it was either a typo, or a conceptual error in setting up the desired binding. Background info for those following along: The bind command (a bash builtin) installs readline key bindings -- in this case, from a file named /mc/bin/xterm_bindings. Readline normally reads custom key bindings from the ~/.inputrc file. This is done automatically, and does not need a bind command to be executed from a dot file. I have no idea why the OP is using this file in addition to, or instead of, the ~/.inputrc file. It's *possible* that the OP wanted different key bindings in bash compared to other programs that use readline, e.g. gdb. That would be one reason to keep two separate files. I have no idea why the second file is kept outside the user's $HOME, though, let alone why the OP has a directory named /mc, or why bash-specific readline key bindings are kept there. I'm also extremely confused why these bindings are only loaded when bash is run inside an X session (the $DISPLAY check). I don't see the point of that at all. If anything, a check for $TERM == xterm might be reasonable (based on the name of the file), but that's not the check that's being used.
Re: single quote "'" in bash xterm or lxterminal
On 26/12/2023 23:57, Mike McClain wrote: Only when xterm_bindings has no executable lines in it does it not kill '"' in an X terminal window. The line that pulled it in was ; [ -n "$DISPLAY" ] && [ -f /mc/bin/xterm_bindings ] && bind -f /mc/bin/xterm_bindings; I do not see anything that may cause the issue with single quote in the following message. I am curious what was the goal of the particular binding that had so detrimental side effect. https://lists.debian.org/msgid-search/20110218064727.GA6305@playground Re: xterm question [SOLVED] Thu, 17 Feb 2011 22:47:27 -0800
Re: single quote "'" in bash xterm or lxterminal
You guys were rigt all along, I just couldn't see it.
Greg's suggestion to try dash showed me the error of my ways.
I moved .inputrc to no.inputrc, commented out the line in
bash.environment that pulled in xterm_bindings, killed and restarted X
and sure enough I had '"' in an lxterminal window.
I moved no.inputrc back to .inputrc, killed and restarted X and still
had '"' in an lxterminal window.
I deleted half of the entries in xterm_bindings, reenabled the
statement in bash.environment, killed and restarted X and
lost '"' in an lxterminal window.
I deleted another half of the entries in xterm_bindings,
killed and restarted X and still no '"' in an lxterminal window.
Only when xterm_bindings has no executable lines in it does it not
kill '"' in an X terminal window.
The line that pulled it in was ;
[ -n "$DISPLAY" ] && [ -f /mc/bin/xterm_bindings ] && bind -f
/mc/bin/xterm_bindings;
Greg I have no idea when this happened xterm_bindings was started in 2011
and either I didn't notice it or it wasn't a big enough problem to
deal with. I keep tty{1-10} open all the time and X only on tty11 so
seldom use a terminal window in X.
Thanks for your help fellows and Happy Holidays,
May the new year be good for you,
Mike
--
Never ascribe to stupidity what can be explained as ignorance.
Re: single quote "'" in bash xterm or lxterminal
On 25/12/2023 12:31, Mike McClain wrote: In lxterminal control v displays "'" though lxterminal doesn't. Do xterm and lxterminal behave in a similar way? Is there something related to xterm *VT100*translations in the output of xrdb -query - I am unsure if there are terminal settings and capabilities that may affect "'". Anyway echo $TERM What happens if single quote is typed when "cat" is running? Does behavior of bash change when it is running in "screen" or "tmux" in VT or in a GUI terminal application. They use different terminal types. To check if bash receives "'" you may attach to it by "strace -p PID" running in another window. To get PID you may use "echo $$". Maybe I have missed it, but it is not clear for me if you use X11 or Wayland. However I have no ideas specific to session type. May it happen that you have configured some input method, e.g. iBus?
Re: single quote "'" in bash xterm or lxterminal
On Mon, Dec 25, 2023 at 12:35:37PM -0600, Mike McClain wrote: > root@RPI4b3:~> tty; echo $SHELL; echo "' " | hd For the record, $SHELL does not tell you what shell you're currently in. It tells you which login shell your account uses, or which shell you'd *like* to use when you launch a new xterm (et al.) or when you shell-escape from programs that offer this feature. To see what shell you're currently in, try: ps -p $$ > As this demonstrates, I get single quotes in bash in a VT but not in X. But you DO get single-quotes in jed in X, or in dash in X?
Re: single quote "'" in bash xterm or lxterminal
root@RPI4b3:~> tty; echo $SHELL; echo "' " | hd /dev/tty1 /bin/bash 27 20 0a |' .| 0003 mike@RPI4b3:~> tty; echo $SHELL; echo "' " | hd /dev/tty6 /bin/bash 27 20 0a |' .| 0003 mike@RPI4b3:~> tty; echo $SHELL; echo " " | hd /dev/pts/1 /bin/bash 20 0a | .| 0002 The above in a lxterminal window. mike@RPI4b3:~> tty; echo $SHELL; echo " " | hd /dev/pts/6 /bin/bash 20 0a | .| 0002 The above in an term window. As this demonstrates, I get single quotes in bash in a VT but not in X. I see the same whether beforre or after executing 'setxkbmap -layout us'. Suggestions for further exploration? Merry Christmas, Mike -- Under capitalism man exploits man; under socialism the reverse is true' - Polish Proverb.
Re: single quote "'" in bash xterm or lxterminal
On Sun, Dec 24, 2023 at 11:31:09PM -0600, Mike McClain wrote: > I've examined /etc/inputrc, .inputrc, /etc/bash.bashrc, ~/.bashrc, > /etc/profile, /etc/profile.d/*, ~/.profile, ~/.bash_profile, OK, you've examined them... and... what did you *see* in them? When did this problem start to happen, and which of these files were edited right before then? Oh, and just for additional data: if you start a terminal, and then run "dash" (or any other shell that isn't bash), does the problem go away, or does it still happen? (I'm pretty sure it'll go away, same as it does when you run "jed", but it's good to verify.)
Re: single quote "'" in bash xterm or lxterminal
This is reported by "xev" in response to the "'" key:
KeyPress event, serial 48, synthetic NO, window 0x1e1,
root 0x3af, subw 0x0, time 1860575, (170,-87), root:(1005,201),
state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
XLookupString gives 1 bytes: (27) "'"
XmbLookupString gives 1 bytes: (27) "'"
XFilterEvent returns: False
In lxterminal control v displays "'" though lxterminal doesn't.
"''" shows nothing and "'a" shows "a",
likewise "'e" = "e", "'o" = "o", etc.
I've examined /etc/inputrc, .inputrc, /etc/bash.bashrc, ~/.bashrc,
/etc/profile, /etc/profile.d/*, ~/.profile, ~/.bash_profile,
both of the latter two just pull in ~/.bashrc which pulls in
bash.{aliases,environment,functions} which are just stuff that started out
in ~/.bashrc but got split out when it got unwieldy.
The only things I've got that tweek the keyboard are
/mc/bin/setkeys which is run by /etc/rc.local
and /mc/bin/xterm_bindings pulled in by bash.environment.
Both of these contain keyboard assignments for bash/readline editing functions
or jed editing functions and don't change how a single quote is handled.
They have been around so long they probably predate my awareness of inputrc.
98% of what is /mc/bin I wrote plus a few things I ran across and kept for
the ideas/lessons they taught.
mike@RPI4b3:~> cat /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS="compose:lwin"
BACKSPACE="guess"
Durring the hours I've spent exploring this problem it has occured to me to
wonder why I would see this problem only in a desktop terminal window
but not on tty(1-10)? That suggests to me that it is not a readline problem
but I don't know much about keyboard mapping in X or wayland as I'm under now.
Suggestions on where to look next?
Thanks for your ideas and Merry Christmas,
Mike
--
No one's life, liberty, or property is safe while
the legislature is in session.
- Mel Greene's _The_Greatest_Joke_Book_Ever_
Re: single quote "'" in bash xterm or lxterminal
On Sat, Dec 23, 2023 at 09:06:47PM -0500, Greg Wooledge wrote: > On Sun, Dec 24, 2023 at 09:01:09AM +0700, Max Nikulin wrote: > > On 24/12/2023 07:32, Mike McClain wrote: > > > when I > > > type a single quote "'" in bash xterm or lxterminal nothing shows. > > > > May it happen that you have dead keys in your keyboard configuration to type > > characters with accents? I have never used this feature, so my guess may be > > wrong. What happens if you type single quote twice "''"? What happens if it > > is followed by a letter "'a"? > > > > cat /etc/default/keyboard > > > > What is reported by "xev" in response to the "'" key? > > If it were a "dead keys" feature in the keyboard driver, I would expect > that to affect his text editor as well as his shell. But he claimed > that this behavior occurs only in the shell. That makes me think it's > a readline key binding that has been mangled. My thought also. But ruling that out is easy, so... Mike: what happens if you type the single quote twice in your terminal? What happens if you type single quote, then space? Cheers -- t signature.asc Description: PGP signature
Re: single quote "'" in bash xterm or lxterminal
On Sun, Dec 24, 2023 at 09:01:09AM +0700, Max Nikulin wrote: > On 24/12/2023 07:32, Mike McClain wrote: > > when I > > type a single quote "'" in bash xterm or lxterminal nothing shows. > > May it happen that you have dead keys in your keyboard configuration to type > characters with accents? I have never used this feature, so my guess may be > wrong. What happens if you type single quote twice "''"? What happens if it > is followed by a letter "'a"? > > cat /etc/default/keyboard > > What is reported by "xev" in response to the "'" key? If it were a "dead keys" feature in the keyboard driver, I would expect that to affect his text editor as well as his shell. But he claimed that this behavior occurs only in the shell. That makes me think it's a readline key binding that has been mangled.
Re: single quote "'" in bash xterm or lxterminal
On 24/12/2023 07:32, Mike McClain wrote: when I type a single quote "'" in bash xterm or lxterminal nothing shows. May it happen that you have dead keys in your keyboard configuration to type characters with accents? I have never used this feature, so my guess may be wrong. What happens if you type single quote twice "''"? What happens if it is followed by a letter "'a"? cat /etc/default/keyboard What is reported by "xev" in response to the "'" key?
Re: single quote "'" in bash xterm or lxterminal
On Sat, Dec 23, 2023 at 06:32:35PM -0600, Mike McClain wrote: > I seldom use the command line while on the desk top since I keep 10 > VTs open for day to day tasks so only recently noticed that when I > type a single quote "'" in bash xterm or lxterminal nothing shows. If > I open a file for editing with jed, my favorite editor, I can type a > single quote but back on the CL again no "'". > Suggestions on where to look for a solution? Most likely something in your ~/.inputrc file, if you have one. It could also be in /etc/inputrc (global version of ~/.inputrc), or in any dot files that are read during shell startup (~/.bashrc or /etc/bash.bashrc or other files that are sourced or dotted in by one of these, including profiles if this is a login shell). In any case, this sounds very much like a readline binding issue, which points toward inputrc more than anything else.
single quote "'" in bash xterm or lxterminal
I seldom use the command line while on the desk top since I keep 10 VTs open for day to day tasks so only recently noticed that when I type a single quote "'" in bash xterm or lxterminal nothing shows. If I open a file for editing with jed, my favorite editor, I can type a single quote but back on the CL again no "'". Suggestions on where to look for a solution? Thanks and Merry Christmas, Mike -- Silence & smile are two powerful tools. Smile is the way to solve many problems & Silence is the way to avoid many problems.
Re: bash vs. dash and stdin
On 22/11/2023 19:17, Greg Wooledge wrote: On Wed, Nov 22, 2023 at 07:06:58PM +0700, Max Nikulin wrote: ssh localhost echo remote echo local This is like <https://mywiki.wooledge.org/BashFAQ/089>. ssh grabs all of the stdin (until EOF) and leaves none for bash. Thanks. I expected to find it among pitfalls. I don't know dash's internals. Maybe dash reads an entire buffer's worth of stdin at a time, instead of a command at a time as bash does. It seems dash reads a block from stdin (and does not lseek back even for regular files) only for commands. I do not see significant difference when commands reading stdin are placed into a script cmd='seq 100 | while read -r var ; do printf "%s\n" "$var" ; ssh localhost echo remote ; done' bash -c "$cmd" dash -c "$cmd" If the script is passed as an argument, not to stdin, then output contains "local" in both cases. Yes. In that case, bash is not competing with ssh for stdin. I have found an attempt to report it: https://lore.kernel.org/dash/6640a8ee-eda0-1e35-df1a-c8b303440...@mail.de/ stdin should be consumed line by line. Fri, 22 Oct 2021 13:11:43 +0200 No response.
Re: bash vs. dash and stdin
Max Nikulin (12023-11-22): > Is there a document that describes shell behavior in respect to stdin in > such cases? The shell did not eat your stdin here, ssh did. Regards, -- Nicolas George
Re: bash vs. dash and stdin
On Wed, Nov 22, 2023 at 07:06:58PM +0700, Max Nikulin wrote: > Consider a file (ssh.sh) containing a couple of commands: > >ssh localhost echo remote >echo local > > Let's try to run it (assuming key-based authorization) > > bash remote You're trying to use stdin twice at the same time. You've got bash reading stdin to fetch commands, and you've got ssh reading stdin because that's just what ssh does. This is like <https://mywiki.wooledge.org/BashFAQ/089>. ssh grabs all of the stdin (until EOF) and leaves none for bash. > One might expect to see "local" as well. > > dash remote > local I don't know dash's internals. Maybe dash reads an entire buffer's worth of stdin at a time, instead of a command at a time as bash does. > If the script is passed as an argument, not to stdin, then output contains > "local" in both cases. Yes. In that case, bash is not competing with ssh for stdin.
bash vs. dash and stdin
Hi, There was a thread on stdio buffering and fork a month ago. That time I thought shells should be rather careful with input/output handling when spawning subprocesses. Consider a file (ssh.sh) containing a couple of commands: ssh localhost echo remote echo local Let's try to run it (assuming key-based authorization) bash Is there a document that describes shell behavior in respect to stdin in such cases? If the script is passed as an argument, not to stdin, then output contains "local" in both cases. I admit that ssh (called this way) can not avoid consuming of some stdin, so bash behavior may be considered a bit more correct despite initial expectations. If you are going to try strace then, to make difference more prominent, it is better to force creation of a pipe cat ssh.sh | strace bash I am curious if it may be a dash bug or it is just falls into the category of unspecified behavior. P.S. I noticed it in a discussion whether a command not executed after ssh is an Emacs bug. My conclusion is that "ssh -n" should be used in scripts unless a remote command really needs stdin.
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 06:42:42PM -0400, Karl Vogel wrote: > If you're running bash, the safest way to find your current working > directory is capturing the output from /bin/pwd. Symlinked directories > can surprise you: > > me$ cd > > me$ ls -ldF today > lrwxr-xr-x 1 me mis 18 Aug 26 00:03 today@ -> notebook/2023/0826 > > me$ cd today > > me$ pwd > /home/me/today > > me$ /bin/pwd > /home/me/notebook/2023/0826 > > me$ echo $PWD > /home/me/today unicorn:~$ help pwd pwd: pwd [-LP] Print the name of the current working directory. Options: -Lprint the value of $PWD if it names the current working directory -Pprint the physical directory, without any symbolic links By default, `pwd' behaves as if `-L' were specified. [...] Of course, this is all a big tangent from the original request.
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 12:09:57PM -0400, Tom Browder wrote:
> Excellent mind-reading, Greg! So to use your line I will put in that dir:
> "cd /required-dir || exit"
>
> Thanks so much. And thanks to all others who responded.
If you're running bash, the safest way to find your current working
directory is capturing the output from /bin/pwd. Symlinked directories
can surprise you:
me$ cd
me$ ls -ldF today
lrwxr-xr-x 1 me mis 18 Aug 26 00:03 today@ -> notebook/2023/0826
me$ cd today
me$ pwd
/home/me/today
me$ /bin/pwd
/home/me/notebook/2023/0826
me$ echo $PWD
/home/me/today
If you want to know why you had an early exit:
me$ cat try
#!/usr/bin/env bash
# try: test logging.
export PATH=/usr/local/bin:/bin:/usr/bin
set -o nounset # check for unbound variables.
tag=${0##*/}
umask 022
# Test file descriptor 2 for interactive or cron use.
test -t 2
case "$?" in
0) logmsg () { echo "$(date '+%F %T') $tag: $@"; } ;;
*) logmsg () { logger -t $tag "$@"; } ;;
esac
warn () { logmsg "WARN: $@" ; }
die () { logmsg "FATAL: $@"; exit 1 ; }
# Real work starts here.
case "$#" in
0) die "need a directory" ;;
*) dir="$1" ;;
esac
test -d "$dir" || die "$dir: not a directory"
cd "$dir" || die "$dir: cannot cd"
cwd=$(/bin/pwd)
logmsg "start working in $cwd"
exit 0
On FreeBSD, you can use "daemon" to run something detached from the
controlling terminal, which simulates running a cron job:
me$ ls -ldF /etc /var/authpf
drwxr-xr-x 27 root wheel 120 26-Aug-2023 07:55:02 /etc/
drwxrwx--- 2 root authpf 2 05-Jul-2019 00:45:45 /var/authpf/
me$ ./try /etc
2023-08-26 18:31:54 try: start working in /etc
me$ daemon -f $PWD/try /etc
me$ daemon -f $PWD/try /var/authpf
me$ tail -2 /var/log/syslog
Aug 26 18:19:17 myhost try: start working in /etc
Aug 26 18:19:19 myhost try: FATAL: /var/authpf: cannot cd
Hope this helps.
--
Karl Vogel I don't speak for anyone but myself.
Oh, my darlin' had bronchitis and she barfed up half a lung,
what came up looked quite amazing when she rolled it on her tongue.
--sung to the tune of "My Darling Clementine"
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 01:54:41PM -0500, Tom Browder wrote: > On Sat, Aug 26, 2023 at 10:42 wrote: [...] > > Basically it is not possible to find out [...] > As I think I replied earier, I am now checking the script is in the > required directory in order to be executed (by the root user) [...] Yes, it seems our posts crossed. Anyway, glad you found a solution. Cheers -- t signature.asc Description: PGP signature
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 10:42 wrote: > On Sat, Aug 26, 2023 at 04:45:54PM +0200, DdB wrote: > > Am 26.08.2023 um 16:25 schrieb Tom Browder: > > > Is there a way to distinguish whether 'sudo -i' was used or not? > > > > > Sorry, i am not an expert on this. But ... since years i am using this > > to check for it: > > > > > # if `echo $HOME` is not "/root" or the working dir (pwd) is not > "/root", then this was not executed with "sudo -i" > > > assert "echo $HOME" /root "nicht mit sudo -i aufgerufen" > > > assert pwd /root "nicht mit sudo -i aufgerufen" > > > > hope, this will give you a clue ;-) > > DdB > > Unless, of course, the shell does "export HOME=/root" at some point > after start. Or one of the other fifty-two ways to achieve that. > > That's why I think Roberto is right elsewhere in this thread. > > Basically it is not possible to find out, so it makes sense to > think about the question "why do I need this?" to zoom into what > the real problem is. Perhaps that one can be solved :-) As I think I replied earier, I am now checking the script is in the required directory in order to be executed (by the root user). I am not concerned with any other caveats or use by any unauthorized users for any nefarious purpose. I consider this thread completed. Thanks to all who responded--Debian users are the best! -Tom
Re: Using the bash shell: determine if the root user used 'sudo -i'
* On 2023 26 Aug 11:10 -0500, Tom Browder wrote: > On Sat, Aug 26, 2023 at 10:57 Greg Wooledge wrote: > > > On Sat, Aug 26, 2023 at 10:49:45AM -0500, Tom Browder wrote: > > > I would like to know whether 'sudo -i' or 'sudo -s' was used. > > ... > > > In fact, I suspect "I need to know if the cwd is /root" is STILL an X-Y > > problem. It's sounding like "I need to ensure my script's working > > directory is /foo". If that's truly the case, just do "cd /foo || exit" > > at the top of the script. > > ... > > Excellent mind-reading, Greg! So to use your line I will put in that dir: > > "cd /required-dir || exit" In such cases I prefer specifying the complete paths in the script so as not to get lost. If the script needs to work in a specific directory of root I'll put: cd /root/dir/dir1 or something like: cd /home/username/dir and so on (adding whatever error recovery is needed). If I need to source a file I just type in the complete path name. It's a one time bother and the executing shell doesn't care and as the script gets more complex it's much easier to keep one's bearings on where the script is working at various points. As I see it, relative paths are more for interactive shell use. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 11:56:27AM -0400, Greg Wooledge wrote: > On Sat, Aug 26, 2023 at 10:49:45AM -0500, Tom Browder wrote: > > I would like to know whether 'sudo -i' or 'sudo -s' was used. > > That's STILL an X-Y problem. > > > The reason is > > to know if the cwd is set to '/root' or '.' It's critical for the script > > execution > > Oh? Then just look at the current working directory. It's in the $PWD > variable. I guess it's better use the shell builtin pwd: PWD=/not/such/file/or/directory echo "cwd=" $(pwd) "PWD=" $PWD (Note: your shell prompt might be a bit... messed up after that) > You don't actually need to know what was typed. Yep, that was my hunch, too. Cheers -- t signature.asc Description: PGP signature
Re: Using the bash shell: determine if the root user used 'sudo -i'
On 26 Aug 2023 11:56 -0400, from g...@wooledge.org (Greg Wooledge): > You don't actually need to know what was typed. And even being able to answer the question "how was sudo executed" doesn't solve the problem of ensuring that the script is executing within a particular directory. All it takes is the user cd'ing to a different directory before running the script. > In fact, I suspect "I need to know if the cwd is /root" is STILL an X-Y > problem. Agreed. Also, a few things worth noting: * The current working directory will ALWAYS be ".". That's what "." at the beginning of a relative path _means_. So testing the current working directory against the actual path corresponding to "." will always return a truthy result. * The home directory of the root user won't necessarily be /root. By convention it often is, but there's no guarantee that this is the case. * There can be multiple users with the same numerical user ID (including 0), with different user names and home directories but access to the same files. The BSDs do this often; Linux systems more rarely so, but it's absolutely possible. And that's just what I can think of off the top of my head. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 10:57 Greg Wooledge wrote: > On Sat, Aug 26, 2023 at 10:49:45AM -0500, Tom Browder wrote: > > I would like to know whether 'sudo -i' or 'sudo -s' was used. ... > In fact, I suspect "I need to know if the cwd is /root" is STILL an X-Y > problem. It's sounding like "I need to ensure my script's working > directory is /foo". If that's truly the case, just do "cd /foo || exit" > at the top of the script. ... Excellent mind-reading, Greg! So to use your line I will put in that dir: "cd /required-dir || exit" Thanks so much. And thanks to all others who responded. -Tom
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 10:49:45AM -0500, Tom Browder wrote: > I would like to know whether 'sudo -i' or 'sudo -s' was used. That's STILL an X-Y problem. > The reason is > to know if the cwd is set to '/root' or '.' It's critical for the script > execution Oh? Then just look at the current working directory. It's in the $PWD variable. You don't actually need to know what was typed. In fact, I suspect "I need to know if the cwd is /root" is STILL an X-Y problem. It's sounding like "I need to ensure my script's working directory is /foo". If that's truly the case, just do "cd /foo || exit" at the top of the script.
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 09:32 Roberto C. Sánchez wrote: > On Sat, Aug 26, 2023 at 09:25:10AM -0500, Tom Browder wrote: > >In a previous thread it was shown how to detect a SUDO_USER in a bash > >shell. > >Is there a way to distinguish whether 'sudo -i' was used or not? I would like to know whether 'sudo -i' or 'sudo -s' was used. The reason is to know if the cwd is set to '/root' or '.' It's critical for the script execution -Tom
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 04:45:54PM +0200, DdB wrote: > Am 26.08.2023 um 16:25 schrieb Tom Browder: > > Is there a way to distinguish whether 'sudo -i' was used or not? > > > Sorry, i am not an expert on this. But ... since years i am using this > to check for it: > > > # if `echo $HOME` is not "/root" or the working dir (pwd) is not "/root", > > then this was not executed with "sudo -i" > > assert "echo $HOME" /root "nicht mit sudo -i aufgerufen" > > assert pwd /root "nicht mit sudo -i aufgerufen" > > hope, this will give you a clue ;-) > DdB Unless, of course, the shell does "export HOME=/root" at some point after start. Or one of the other fifty-two ways to achieve that. That's why I think Roberto is right elsewhere in this thread. Basically it is not possible to find out, so it makes sense to think about the question "why do I need this?" to zoom into what the real problem is. Perhaps that one can be solved :-) Cheers -- t signature.asc Description: PGP signature
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 09:25:10AM -0500, Tom Browder wrote: > In a previous thread it was shown how to detect a SUDO_USER in a bash shell. > > Is there a way to distinguish whether 'sudo -i' was used or not? I have not tested this but if bash was interactive you will find a .bash_history file in their $HOME. That assumes that they have not logged in - ie only ever sudo. > Thanks. > > -Tom -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Using the bash shell: determine if the root user used 'sudo -i'
Am 26.08.2023 um 16:25 schrieb Tom Browder: > Is there a way to distinguish whether 'sudo -i' was used or not? > Sorry, i am not an expert on this. But ... since years i am using this to check for it: > # if `echo $HOME` is not "/root" or the working dir (pwd) is not "/root", > then this was not executed with "sudo -i" > assert "echo $HOME" /root "nicht mit sudo -i aufgerufen" > assert pwd /root "nicht mit sudo -i aufgerufen" hope, this will give you a clue ;-) DdB
Re: Using the bash shell: determine if the root user used 'sudo -i'
On Sat, Aug 26, 2023 at 09:25:10AM -0500, Tom Browder wrote: >In a previous thread it was shown how to detect a SUDO_USER in a bash >shell. >Is there a way to distinguish whether 'sudo -i' was used or not? >Thanks. >-Tom The SUDO_COMMAND environment variable would report /bin/bash in that instance. Would that be sufficient for your needs? If not, then what exactly are you trying to accomplish? Please don't say "I want to know if sudo -i was used" because we already know that. Why is that a necessary piece of information in your use case? What will you do with that information? What decision will you make? What action will you take? Regards, -Roberto -- Roberto C. Sánchez
Using the bash shell: determine if the root user used 'sudo -i'
In a previous thread it was shown how to detect a SUDO_USER in a bash shell. Is there a way to distinguish whether 'sudo -i' was used or not? Thanks. -Tom
BASH {VARNAME}>&- redirection (was: Re: Konsole is not bash)
On 23/08/2023 02:59, Greg Wooledge wrote:
bar() {
local fd
foo {fd}>&1 1>&2 2>&${fd} {fd}>&-
}
Running this appears to gives the correct results -- outputs go to the
right places -- but it leaves the temporary FD open. The final
redirection to close it doesn't work.
At first glance it is documented and effect of {fd}>&- is limited to the
function call
info "(bash) Redirections"
If {VARNAME} is supplied, the redirection persists
beyond the scope of the command, allowing the shell programmer to manage
the file descriptor's lifetime manually. The 'varredir_close' shell
option manages this behavior (*note The Shopt Builtin::).
info "(bash) The Shopt Builtin"
'varredir_close'
If set, the shell automatically closes file descriptors
assigned using the '{varname}' redirection syntax (*note
Redirections::) instead of leaving them open when the command
completes.
However the redirection does not persist if an external executable is
called instead of a BASH function. Perhaps it should be discussed with
BASH developers.
foo() {
sh -c 'echo "internal $1" /proc/self/fd/*' foo "$1"
}
bar() {
local fd
sh -c "echo 'external before' /proc/self/fd/*"
sh -c "echo 'external closed' /proc/self/fd/*" {fd}>&1 1>&2
2>&${fd} {fd}>&-
sh -c "echo 'external after ' /proc/self/fd/*"
echo "fd: $fd"
sh -c "echo 'external before' /proc/self/fd/*"
sh -c "echo 'external open ' /proc/self/fd/*" {fd}>&1 1>&2 2>&${fd}
sh -c "echo 'external after ' /proc/self/fd/*"
echo "fd: $fd"
echo
sh -c "echo 'internal before' /proc/self/fd/*"
foo "closed" {fd}>&1 1>&2 2>&${fd} {fd}>&-
sh -c "echo 'internal after ' /proc/self/fd/*"
echo "fd: $fd"
if [ -n "$fd" ]; then exec {fd}>&-; fd=; fi
sh -c "echo 'internal before' /proc/self/fd/*"
foo "open " {fd}>&1 1>&2 2>&${fd}
sh -c "echo 'internal after ' /proc/self/fd/*"
echo "fd: $fd"
if [ -n "$fd" ]; then exec {fd}>&-; fd=; fi
}
bar
Pay attention to {fd} that is is 10, other may be ignored, in particular
/proc/self/fd opened by readdir is 3, some inotify is 20 below.
external before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
external closed /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
external after /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
fd:
external before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
external open /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
external after /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
fd:
internal before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
internal closed /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
internal after /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
fd: 10
internal before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2
/proc/self/fd/20 /proc/self/fd/3
internal open /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
internal after /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
fd: 10
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Greg Wooledge
bar() {
local fd rc
foo {fd}>&1 1>&2 2>&${fd}
rc=$?
exec {fd}>&-
return "$rc"
}
I have not tested if "trap" is more robust in the presence of "set -e -o
pipefail". I know, there are enough pitfalls with this options.
At this point, the "pure sh" version looks a whole lot simpler,
doesn't it?
You mentioned the limitation: a spare file descriptor must be known.
Re: Konsole is not bash
See, this is why I hate using bash extensions. So many weird corner
cases and surprises
As it turns out, the answer I gave yesterday was only partially correct.
The "pure sh" solution is fine, but I offered this bash alternative:
cmd {fd}>&1 1>&2 2>&$fd {fd}>&-
This doesn't actually work as expected. It fails to close the FD in the
final redirection.
What does it actually do? Hell if I know. I literally can't figure it
out.
Consider this function:
foo() { echo out; echo err >&2; }
Simple enough, right? It writes "out" to stdout, and "err" to stderr. We
can use this to see what's going where, while we play games with
redirections.
Next, we write a simple wrapper, which should in theory swap stdout and
stderr:
bar() {
local fd
foo {fd}>&1 1>&2 2>&${fd} {fd}>&-
}
Running this appears to gives the correct results -- outputs go to the
right places -- but it leaves the temporary FD open. The final
redirection to close it doesn't work.
But *this* one works:
bar() {
local fd
foo {fd}>&1 1>&2 2>&${fd}
exec {fd}>&-
}
Why? Again, I do not know. My theories all fail to account for all of
the observed results. And, of course, if we wanted to preserve the exit
status of foo, the second wrapper script doesn't do that. It'll need
another variable to hold that:
bar() {
local fd rc
foo {fd}>&1 1>&2 2>&${fd}
rc=$?
exec {fd}>&-
return "$rc"
}
At this point, the "pure sh" version looks a whole lot simpler,
doesn't it?
THIS is why I have a wiki devoted to bash and its problems.
Re: Konsole is not bash
On Mon, Aug 21, 2023 at 09:19:00AM +0700, Max Nikulin wrote:
> On 21/08/2023 01:48, Greg Wooledge wrote:
> > Some shell features do change over time, but the significant
> > ordering of redirections has remained stable ever since the original
> > Bourne shell.
>
> An exercise that relies on order of redirections and thus demonstrates its
> importance:
>
> Swap stderr and stdout of a shell command.
Hmm. I thought <https://mywiki.wooledge.org/BashFAQ/047> might have
it, but it doesn't. Some examples are pretty close, but none are an
exact match.
cmd 3>&1 1>&2 2>&3 3>&-
Obviously this relies on FD 3 not being in use at that point. In pure
sh, you'd need to have knowledge of *some* FD number which is available.
In bash, you can use {somevar}>&1 to let the shell pick an FD for you,
but that's an extension.
cmd {fd}>&1 1>&2 2>&$fd {fd}>&-
Re: Konsole is not bash
On 21/08/2023 01:05, Felix Miata wrote: In the most recent versions of Konsole I've started (5.27.x), the default profile has inexplicably been changed from /bin/bash to /bin/sh. Is it konsole or plasma version? May it happen that /bin/sh was just saved to your konsole config files or it is your shell specified in /etc/passwd?
Re: Konsole is not bash
On 21/08/2023 01:48, Greg Wooledge wrote: Some shell features do change over time, but the significant ordering of redirections has remained stable ever since the original Bourne shell. An exercise that relies on order of redirections and thus demonstrates its importance: Swap stderr and stdout of a shell command.
Re: Konsole is not bash
On 8/20/23 14:23, Greg Wooledge wrote: On Sun, Aug 20, 2023 at 02:05:49PM -0400, Felix Miata wrote: Bob Weber composed on 2023-08-20 11:04 (UTC-0400): gene heskett wrote: I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. What terminal actually uses bash for the heavy lifting? In konsole its in the settings for the profile you are using. Mine just says bash not /usr/bin/bash. If a profile uses ssh that will be there also. Its under "Settings/Edit current profile" or "Settings/Manage profiles". In the most recent versions of Konsole I've started (5.27.x), the default profile has inexplicably been changed from /bin/bash to /bin/sh. The redirection syntax Gene is using is the same in all Bourne family shells (anything that /bin/sh may legitimately point to, including dash and bash). Bash has a few extensions, of course, but none of them are in Gene's original message. If there's a legitimate concern that you might be in the wrong shell, this command will tell you which shell is currently active: ps -p $$ Which does indeed confirm its bash. Thanks Greg. That works in all Bourne family and csh family shells, and on all Unix systems (BSD- or System V-derived ps command syntax). Avoid things like "echo $SHELL" because that may give misleading results. The SHELL variable does *not* necessarily match the currently running shell. . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
Re: Konsole is not bash
Gene writes: > And that order of arguments is not mentioned in the bash scripting > manual It isn't an argument. It's an instruction to the shell. See the REDIRECTION section of the bash man page. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Konsole is not bash
On Sun, Aug 20, 2023 at 02:27:38PM -0400, gene heskett wrote: > I should have prefaced cmd with a $ sign but forgot to add it in my post, > cmd was meant to be whatever I wanted to trace, in this case digiKam which > is the current 8.1.0 AppImage, probably updated by now as the do that about > monthly but not yet. Sorry for the confusion. Greg sorted me out, and my > several year old dead tree 500 page tome on bash scripting is out of date. The way redirections work has not changed, ever. It has always been this way. Some shell features do change over time, but the significant ordering of redirections has remained stable ever since the original Bourne shell. Whatever reference material you're using isn't "out of date". It's simply incomplete (or perhaps confusing, or perhaps just plain wrong) as a teaching text. The lack of good books on shell scripting is one of the major reasons why I've had to put so much effort into the Bash FAQ and other documents on my wiki. There are a lot of incorrect or incomplete sources out there, and virtually *every* shell script in existence has massive bugs, which don't trigger only because you don't have sufficiently evil filenames to trigger them. Sadly, that means people usually learn from bad examples, and perpetuate the bugs that they see, without realizing that they're doing it wrong.
Re: Konsole is not bash
On 8/20/23 10:52, Cindy Sue Causey wrote: On 8/20/23, gene heskett wrote: I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. What terminal actually uses bash for the heavy lifting? Well, I started out attempting to play along in xfce4-terminal and received: bash: tmp/cmd.log: No such file or directory Next I tried konsole which surprised me when it was already installed. That's when I noticed there's no "/" in front of tmp so I added it. Was then advised that "cmd" is not installed. I took that as a sign of progress. That makes me now ask: What error message are you receiving IF you are receiving error feedback? Mine's now acting like it would perform properly if "cmd" was installed. Cindy :) N.B. Now remember why konsole is installed. It's still majorly doing all kinds of hinky BAD things with text input. It's still throwing in extra spacing and lunging text all over the place. YUCK. My mistake Cindy. And I don't recall ever seeing it do that here. I like it because it can do tabs, so I have ssh sessions open to all my other machines all on one workspace. From the only comfy chair for that sort of thing in the whole house. ;o)> I should have prefaced cmd with a $ sign but forgot to add it in my post, cmd was meant to be whatever I wanted to trace, in this case digiKam which is the current 8.1.0 AppImage, probably updated by now as the do that about monthly but not yet. Sorry for the confusion. Greg sorted me out, and my several year old dead tree 500 page tome on bash scripting is out of date. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
Re: Konsole is not bash
On Sun, Aug 20, 2023 at 02:05:49PM -0400, Felix Miata wrote: > Bob Weber composed on 2023-08-20 11:04 (UTC-0400): > > > gene heskett wrote: > > >> I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. > >> What > >> terminal actually uses bash for the heavy lifting? > > > In konsole its in the settings for the profile you are using. Mine just > > says > > bash not /usr/bin/bash. If a profile uses ssh that will be there also. > > Its > > under "Settings/Edit current profile" or "Settings/Manage profiles". > > In the most recent versions of Konsole I've started (5.27.x), the default > profile > has inexplicably been changed from /bin/bash to /bin/sh. The redirection syntax Gene is using is the same in all Bourne family shells (anything that /bin/sh may legitimately point to, including dash and bash). Bash has a few extensions, of course, but none of them are in Gene's original message. If there's a legitimate concern that you might be in the wrong shell, this command will tell you which shell is currently active: ps -p $$ That works in all Bourne family and csh family shells, and on all Unix systems (BSD- or System V-derived ps command syntax). Avoid things like "echo $SHELL" because that may give misleading results. The SHELL variable does *not* necessarily match the currently running shell.
Re: Konsole is not bash
On 8/20/23 10:36, Greg Wooledge wrote: On Sun, Aug 20, 2023 at 10:28:44AM -0400, gene heskett wrote: I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. What terminal actually uses bash for the heavy lifting? The terminal is irrelevant. This is entirely done in the shell. Your redirections are backwards. If you want both stdout and stderr in the same file, you need 2>&1 to be *last*. Also, you *might* want /tmp/cmd.log to be an absolute path. cmd >/tmp/cmd.log 2>&1 If tmp is a local directory relative to your working directory, then ignore that change. But the 2>&1 being last matters here. it is local to /home/me. And that order of arguments is not mentioned in the bash scripting manual I printed several years ago. About 500 pages of it. However it just now worked, I now have the log Maik on the digikam list requested, and my dead tree bash script docs are out of date. Many thanks, take care & stay well, Greg. See also <https://mywiki.wooledge.org/BashFAQ/055>. . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
Re: Konsole is not bash
Bob Weber composed on 2023-08-20 11:04 (UTC-0400): > gene heskett wrote: >> I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. >> What >> terminal actually uses bash for the heavy lifting? > In konsole its in the settings for the profile you are using. Mine just says > bash not /usr/bin/bash. If a profile uses ssh that will be there also. Its > under "Settings/Edit current profile" or "Settings/Manage profiles". In the most recent versions of Konsole I've started (5.27.x), the default profile has inexplicably been changed from /bin/bash to /bin/sh. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Konsole is not bash
On 8/20/23 10:28, gene heskett wrote: I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. What terminal actually uses bash for the heavy lifting? Cheers, Gene Heskett. In konsole its in the settings for the profile you are using. Mine just says bash not /usr/bin/bash. If a profile uses ssh that will be there also. Its under "Settings/Edit current profile" or "Settings/Manage profiles". -- *...Bob*
Re: Konsole is not bash
On 8/20/23, gene heskett wrote: > I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in > Konsole. What terminal actually uses bash for the heavy lifting? Well, I started out attempting to play along in xfce4-terminal and received: bash: tmp/cmd.log: No such file or directory Next I tried konsole which surprised me when it was already installed. That's when I noticed there's no "/" in front of tmp so I added it. Was then advised that "cmd" is not installed. I took that as a sign of progress. That makes me now ask: What error message are you receiving IF you are receiving error feedback? Mine's now acting like it would perform properly if "cmd" was installed. Cindy :) N.B. Now remember why konsole is installed. It's still majorly doing all kinds of hinky BAD things with text input. It's still throwing in extra spacing and lunging text all over the place. YUCK. -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Konsole is not bash
On Sun, Aug 20, 2023 at 10:28:44AM -0400, gene heskett wrote: > I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. > What terminal actually uses bash for the heavy lifting? The terminal is irrelevant. This is entirely done in the shell. Your redirections are backwards. If you want both stdout and stderr in the same file, you need 2>&1 to be *last*. Also, you *might* want /tmp/cmd.log to be an absolute path. cmd >/tmp/cmd.log 2>&1 If tmp is a local directory relative to your working directory, then ignore that change. But the 2>&1 being last matters here. See also <https://mywiki.wooledge.org/BashFAQ/055>.
Konsole is not bash
I cannot make bashes redirection (cmd 2>&1 >tmp/cmd.log) work in Konsole. What terminal actually uses bash for the heavy lifting? Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
Hi, please reply to the list in order to keep all readers informed. (It would be ok to Cc my mail address, but it is not necessary.) - Forwarded message from Sakkra Billa - Date: Mon, 14 Aug 2023 09:32:37 +0530 From: Sakkra Billa To: Thomas Schmitt Subject: Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer Thanks for the reply. I tried debian di too but wasn't successful in that either it said that the kernel version for live and installer were not the same. - End forwarded message - The problem is out of my range of experience and probably out of the experience of the other participants here. So you will have to ask the Debian Installer experts what goes wrong. https://wiki.debian.org/DebianInstaller proposes Email: debian-b...@lists.debian.org IRC: #debian-boot To improve your chances for helpful replies you should give them tangible information. At least: - The possibile configuration of the installer, - the commands used to bring it into the directory tree which later becomes the ISO content, - the exact error messages you get from the attempt to use the installer. (Even if this means that you have to manually toggle them into your mail.) Have a nice day :) Thomas
[sakkrabi...@gmail.com: Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer]
- Forwarded message from Sakkra Billa - Date: Sun, 13 Aug 2023 21:35:33 +0530 From: Sakkra Billa To: "Andrew M.A. Cater" Subject: Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer Thanks for the reply, Actually i am not using debian live-build (as it wont work for 512mb ram) rather i am using debootstrap On Sun, Aug 13, 2023 at 8:43 PM Andrew M.A. Cater wrote: > On Sun, Aug 13, 2023 at 06:56:08PM +0530, Sakkra Billa wrote: > > I followed the tutorial from: > > https://www.willhaley.com/blog/custom-debian-live-environment/ to make a > > live custom debian 12 image. In order to install it on my VM I installed > > calamares, calamares-settings-debian and rsync . The live image works > > perfectly and the installation also finishes without errors but when i > > reboot my VM into the installed environment, it boots into grub minimal > > bash line editing mode. On typing boot it says "load the kernel first". I > > did not change any of the calamares settings everything is default. > Please > > guide me that where did i go wrong. > > I don't know the tutorial. I'd suggest asking on IRC channel debian-live on > OFTC or on the debian-live Debian mailing list. > > I think this is sufficiently niche that those two sources of advice may > prove to be better. > > All the very best, as ever, > > Andy Cater > > - End forwarded message -
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
Hi, Sakkra Billa wrote: > I followed the tutorial > from: https://www.willhaley.com/blog/custom-debian-live-environment/ > [www.willhaley.com] to make a live custom debian 12 image. (The xorriso run looks ok.) > In order to > install it on my VM I installed calamares, calamares-settings-debian and .rsync . The live image works perfectly So the aim of the tutorial was achieved. > and the installation also finishes > without errors but when i reboot my VM into the installed environment, it > boots into grub minimal bash line editing mode. On typing boot it says "load > the kernel first". I assume you used calamares for the installation. Obviously it did not give GRUB the right configuration to load the installed Linux kernel. > I did not change any of the calamares settings everything > is default. You will have to look for instructions about calamares. Have a nice day :) Thomas
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
Hi, On Sun, Aug 13, 2023 at 06:56:08PM +0530, Sakkra Billa wrote: >when i reboot my VM into the installed environment, it boots into >grub minimal On typing boot it says "load the kernel first". What kind of VM is this? Which provider, if you are unsure. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
On 13 Aug 2023 18:56 +0530, from sakkrabi...@gmail.com (Sakkra Billa): > but when i > reboot my VM into the installed environment, it boots into grub minimal > bash line editing mode. On typing boot it says "load the kernel first". Sounds to me like GRUB can't find grub.cfg, or it is somehow corrupt. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
On Sun, Aug 13, 2023 at 06:56:08PM +0530, Sakkra Billa wrote: > I followed the tutorial from: > https://www.willhaley.com/blog/custom-debian-live-environment/ to make a > live custom debian 12 image. In order to install it on my VM I installed > calamares, calamares-settings-debian and rsync . The live image works > perfectly and the installation also finishes without errors but when i > reboot my VM into the installed environment, it boots into grub minimal > bash line editing mode. On typing boot it says "load the kernel first". I > did not change any of the calamares settings everything is default. Please > guide me that where did i go wrong. I don't know the tutorial. I'd suggest asking on IRC channel debian-live on OFTC or on the debian-live Debian mailing list. I think this is sufficiently niche that those two sources of advice may prove to be better. All the very best, as ever, Andy Cater
Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer
I followed the tutorial from: https://www.willhaley.com/blog/custom-debian-live-environment/ to make a live custom debian 12 image. In order to install it on my VM I installed calamares, calamares-settings-debian and rsync . The live image works perfectly and the installation also finishes without errors but when i reboot my VM into the installed environment, it boots into grub minimal bash line editing mode. On typing boot it says "load the kernel first". I did not change any of the calamares settings everything is default. Please guide me that where did i go wrong.
Re: bash $MAIL bug in Bookworm
On Wed, Aug 09, 2023 at 04:04:12PM +0100, Alain D D Williams wrote: > I have recently upgraded to Bookworm. > > I have set: > > MAIL=/var/spool/mail/addw > MAILCHECK=60 > > I find that when doing filename expansion, by pressing TAB, that the 'You have > mail' message appears when it should not. In the example below I pressed TAB > after the letter 'T' (which gave me expansion 'TODO'). I am running bash. > > $ me TYou have mail in /var/spool/mail/addw > ODO You can always look for bugs filed against a package in the package's bug page. In this case, this would be here [1]. Your bug looks a lot like this one [2]. It seems to be pretty old (2012), so you might consider politely pinging the maintainer. Cheers [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=bash [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686794 -- t signature.asc Description: PGP signature
bash $MAIL bug in Bookworm
I have recently upgraded to Bookworm. I have set: MAIL=/var/spool/mail/addw MAILCHECK=60 I find that when doing filename expansion, by pressing TAB, that the 'You have mail' message appears when it should not. In the example below I pressed TAB after the letter 'T' (which gave me expansion 'TODO'). I am running bash. $ me TYou have mail in /var/spool/mail/addw ODO Should I report this elsewhere ? Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
