pmount could perhaps be of greater utility?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

pmount could perhaps be of greater utility?

Erik Christiansen
>From the pmount manpage for stretch:

»
 pmount device [ label ]

 This will mount device to a directory below /media if policy is met
 (see below). If  label is given, the mount point will be /media/label,
 otherwise it will be /media/device.
«

 There doesn't seem to be an option for pmount to mount at
 /media/label_read_from_the_media

 To provide that convenient automation, I use:

 $ which lmount
 lmount is a function
 lmount ()
 {
     pmount $1 `e2label $1`
 }

 Is it worth adding a pmount option to provide that simple but useful
 convenience for general consumption?

 Why? Well some days the automounter just doesn't work on my old Debian
 install. The little LED on the stick blinks furiously for seconds on
 end after stick insertion, but then ... nada. No joy on running mount
 to see if the absence of the GUI navigator-thingy really is indicative.
 And my script for off-site backups expects the backup media at the
 mountpoint which the automounter normally sets, based on the label.
 
 Just a thought.

 Erik

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Jonas Smedegaard-2
Quoting Erik Christiansen (2019-05-04 08:43:53)

> >From the pmount manpage for stretch:
>
> »
>  pmount device [ label ]
>
>  This will mount device to a directory below /media if policy is met
>  (see below). If  label is given, the mount point will be /media/label,
>  otherwise it will be /media/device.
> «
>
>  There doesn't seem to be an option for pmount to mount at
>  /media/label_read_from_the_media
>
>  To provide that convenient automation, I use:
>
>  $ which lmount
>  lmount is a function
>  lmount ()
>  {
>      pmount $1 `e2label $1`
>  }
I recommend to install package shellcheck and run "shellcheck lmount".

>  Is it worth adding a pmount option to provide that simple but useful
>  convenience for general consumption?

I don't personally use pmount since some years, but that sure sounds
like a nice suggestion: Please consider filing as a bugreport against
pmount with severity "wishlist".

More info at https://www.debian.org/Bugs/Reporting


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Greg Wooledge
On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> Quoting Erik Christiansen (2019-05-04 08:43:53)
> >  $ which lmount
> >  lmount is a function
> >  lmount ()
> >  {
> >      pmount $1 `e2label $1`
> >  }
>
> I recommend to install package shellcheck and run "shellcheck lmount".

My initial reaction was similar, but he might not be using a regular
shell.  At the very least, his "which" command is not the standard
which(1) utility, because that wouldn't know about shell functions.

So, either he isn't in bash/ksh/dash, or his "which" command has been
overridden with a function or alias.  (On the other hand, his output
from "which" looks identical to bash's "type" output.  So maybe he
did something like alias which=type.)

At the end of the day, if this is supposed to be a bash function, it
has three quoting errors, and is using the ancient deprecated command
substitution syntax (which will work in this case, but is not a good
habit).

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Erik Christiansen
On 06.05.19 09:03, Greg Wooledge wrote:

> On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> > Quoting Erik Christiansen (2019-05-04 08:43:53)
> > >  $ which lmount
> > >  lmount is a function
> > >  lmount ()
> > >  {
> > >      pmount $1 `e2label $1`
> > >  }
> >
> > I recommend to install package shellcheck and run "shellcheck lmount".
>
> My initial reaction was similar, but he might not be using a regular
> shell.  At the very least, his "which" command is not the standard
> which(1) utility, because that wouldn't know about shell functions.
>
> So, either he isn't in bash/ksh/dash, or his "which" command has been
> overridden with a function or alias.  (On the other hand, his output
> from "which" looks identical to bash's "type" output.  So maybe he
> did something like alias which=type.)

Well surmised, good sir. It's more than 30 years since I found "which"
on HP-UX inadequate and "type" meaninglessly mnemonic of "print", thus
the alias. Through SunOS, Solaris, and Linux, the inadequacy has
remained - and so the remedy.

> At the end of the day, if this is supposed to be a bash function, it
> has three quoting errors,

Yep, if the robustness required for users other than an author were
applicable, then I see two absences of double quotes. But it is worth
remembering that there are no robustness requirements when the author is
the only user, and supporting a space in "/dev/xxx" is in any event a
pointless exercise.

> and is using the ancient deprecated command substitution syntax (which
> will work in this case, but is not a good habit).

That does appear to remain opinion. The venerably traditional syntax is
still fully legal supported bash syntax, e.g.:

http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

The recent (late last century, IIRC) introduction of the $(...)
alternative syntax has admittedly brought newer *nix users who know
nothing else, and so delude themselves that there is nothing else. That
is a misapprehension. To each, his own, especially amongst adequately
equivalent alternatives.

HAND

Erik
(Who has used the newfangled syntax on occasion, just to see if it works.)

--
Do not do unto others as you would they should do unto you.            
Their tastes may not be the same.
                                      - George Bernard Shaw

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

David-2
On Mon, 6 May 2019 at 23:53, Erik Christiansen <[hidden email]> wrote:
> On 06.05.19 09:03, Greg Wooledge wrote:
> > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> > > Quoting Erik Christiansen (2019-05-04 08:43:53)

> > > >      pmount $1 `e2label $1`

> > and is using the ancient deprecated command substitution syntax (which
> > will work in this case, but is not a good habit).

> That does appear to remain opinion. The venerably traditional syntax is
> still fully legal supported bash syntax, e.g.:
>
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
>
> The recent (late last century, IIRC) introduction of the $(...)
> alternative syntax has admittedly brought newer *nix users who know
> nothing else, and so delude themselves that there is nothing else. That
> is a misapprehension. To each, his own, especially amongst adequately
> equivalent alternatives.

Hi Erik

Maybe you would enjoy answering this question then?
https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html

Because apparently no-one else has, hehe :D

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Erik Christiansen
On 07.05.19 10:12, David wrote:

> On Mon, 6 May 2019 at 23:53, Erik Christiansen <[hidden email]> wrote:
> > On 06.05.19 09:03, Greg Wooledge wrote:
> > > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> > > > Quoting Erik Christiansen (2019-05-04 08:43:53)
>
> > > > >      pmount $1 `e2label $1`
>
> > > and is using the ancient deprecated command substitution syntax (which
> > > will work in this case, but is not a good habit).
>
> > That does appear to remain opinion. The venerably traditional syntax is
> > still fully legal supported bash syntax, e.g.:
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
> >
> > The recent (late last century, IIRC) introduction of the $(...)
> > alternative syntax has admittedly brought newer *nix users who know
> > nothing else, and so delude themselves that there is nothing else. That
> > is a misapprehension. To each, his own, especially amongst adequately
> > equivalent alternatives.
>
> Hi Erik
>
> Maybe you would enjoy answering this question then?
> https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
>
> Because apparently no-one else has, hehe :D

I can see why - the question wilfully exploits the fact that bash is not
a full programming language, and only the author is dumb enough to construct
such self defeating perversity as using two echos to fabricate difficulty
where none need exist. (Please read next paragraph before kneejerking.)

In a real case of substitution of more substantial commands, it is both
simple and convenient to perform the operations sequentially (i.e. on
separate lines), rather than obfuscate with unnecessary nesting.

Having an intermediate result in a shell variable can often save a lot
of debugging time, both during script development and later, when
unanticipated input causes undesired effects. Having to deconstruct a long
nested assemblage in order to debug it leads to a chained implementation
in any event.

Erik

--
Good judgement comes from experience.
Experience comes from bad judgement.                      - Jim Horning

Reply | Threaded
Open this post in threaded view
|

Remove nautilus to stop automounts? [Was: Re: pmount could perhaps be of greater utility?

Erik Christiansen
In reply to this post by Jonas Smedegaard-2
On 04.05.19 13:48, Jonas Smedegaard wrote:
> Quoting Erik Christiansen (2019-05-04 08:43:53)
> >  There doesn't seem to be an option for pmount to mount at
> >  /media/label_read_from_the_media
...
> I don't personally use pmount since some years, but that sure sounds
> like a nice suggestion: Please consider filing as a bugreport against
> pmount with severity "wishlist".

Hmmm, reportbug says:

Your version (0.9.23-2) of pmount appears to be out of date.
The following newer release(s) are available in the Debian archive:
  experimental: 0.9.99-alpha-1
  unstable: 0.9.23-3+b2
Do you still want to file a report [y|N|q|?]? N

but

# apt-get update
# apt-get install pmount

gives:

pmount is already the newest version.

so I'd probably have to move from wheezy to something newer to be up to
date on that utility. No time for that now.

The nifty pmount feature becomes unnecessary if I instead disable the
automounter, eliminating label-defined mountpoints. But:

# apt-get install dconf-editor      # gives:

The following packages have unmet dependencies:
 dconf-editor : Depends: libdconf1 (>= 0.25.1) but it is not going to be installed
                Depends: libglib2.0-0 (>= 2.55.1) but 2.33.12+really2.32.4-5 is to be installed
                Depends: libgtk-3-0 (>= 3.22.0) but 3.4.2-7+deb7u1 is to be installed

so the easiest way might just be to remove nautilus, as it's never been
used here. The gnome DE wouldn't fall over without it?  

Erik

Reply | Threaded
Open this post in threaded view
|

Re: Remove nautilus to stop automounts? [Was: Re: pmount could perhaps be of greater utility?

Brian
On Tue 07 May 2019 at 21:34:14 +1000, Erik Christiansen wrote:

> On 04.05.19 13:48, Jonas Smedegaard wrote:
> > Quoting Erik Christiansen (2019-05-04 08:43:53)
> > >  There doesn't seem to be an option for pmount to mount at
> > >  /media/label_read_from_the_media
> ...
> > I don't personally use pmount since some years, but that sure sounds
> > like a nice suggestion: Please consider filing as a bugreport against
> > pmount with severity "wishlist".
>
> Hmmm, reportbug says:
>
> Your version (0.9.23-2) of pmount appears to be out of date.
> The following newer release(s) are available in the Debian archive:
>   experimental: 0.9.99-alpha-1
>   unstable: 0.9.23-3+b2
> Do you still want to file a report [y|N|q|?]? N

Of course you want to file a report! You have looked at the changelogs
for unstable and experimental and read their manuals. There is no sign
of your issue being addressed. Edit the version you are reporting the
bug against to 0.9.23-3+b2.

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Greg Wooledge
In reply to this post by David-2
On Tue, May 07, 2019 at 10:12:10AM +1000, David wrote:
> Maybe you would enjoy answering this question then?
> https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
>
> Because apparently no-one else has, hehe :D

You didn't like my answer?

(The OP clarified in a subsequent post that (s)he is trying to implement
syntax highlighting for some kind of text editor.  (S)he wants to support
the behavior of this ridiculous code just in case some foolish end
user writes it.  (S)he's not actually writing a script.  For people who
*are* actually writing scripts, the solution is exactly as I described.)

Reply | Threaded
Open this post in threaded view
|

Netiquette [Was: Re: pmount could perhaps be of greater utility?

Erik Christiansen
In reply to this post by Erik Christiansen
On 07.05.19 07:38, [hidden email] wrote off-list:
> On Tuesday, May 07, 2019 12:01:49 AM Erik Christiansen wrote:
> >  only the author is dumb enough
>
> Why use language like that?  (It does not contribute to the welcoming
> environment that I'd like to see cultivated here.)
>
> Aside: I've replied privately, but I would like to reply publically (sp?) in
> order to spread the message, but only if you feel comfortable with that (which
> I don't expect you will).)

If my judgemental wording has offended the author on the other list,
then I will admit to careless use of language. The out-of-the-blue shot
across my bow from David, using that awkwardly and unproductively
constructed use case looked like a deliberate straw man attack, coming
hot on the heels of a deprecation attempt. Where a shell provides syntax
alternatives, all still documented and supported, it may be perceived as
unwelcoming and unproductive to spontaneously hound one usage in favour
of one's own bias. Still, it would be better if my response had been more
sanguine.

Erik

P.S. s/publically/publicly   (Yep, spellchecking in Vim in Mutt is OK
                              with that. Caveat: I use a British
                              dictionary. Haven't checked for possible USA
                              divergent spelling.)
--
Time is a great teacher, but unfortunately it kills all its pupils.
                                              - Hector Louis Berlioz

Reply | Threaded
Open this post in threaded view
|

Re: Netiquette [Was: Re: pmount could perhaps be of greater utility?

rhkramer

Thanks for your reply, and thanks for putting it on the list!

 

Oh, and thanks for checking the spelling (kmail, at least the version I use, doesn't check spelling (or maybe I haven't enabled spellcheck).

 

(I may check the US spelling at some point -- ah, ok, a quick google finds:

 

<quote>

“Publicly” and “publically” | Stroppy Editor


https://stroppyeditor.wordpress.com/2014/12/09/publicly-and-publically/

Dec 9, 2014 - It's widely regarded as a mistake (although some dictionaries now list it as a variant spelling). But the approved spelling, “publicly”, is a unique ...

</quote>

 

So, I'll use "publicly" -- I was going to do that, but it just seemed wrong at the time ;-)

 

Have a good day!

 

On Tuesday, May 07, 2019 08:41:16 AM Erik Christiansen wrote:

> If my judgemental wording has offended the author on the other list,

> then I will admit to careless use of language. The out-of-the-blue shot

> across my bow from David, using that awkwardly and unproductively

> constructed use case looked like a deliberate straw man attack, coming

> hot on the heels of a deprecation attempt. Where a shell provides syntax

> alternatives, all still documented and supported, it may be perceived as

> unwelcoming and unproductive to spontaneously hound one usage in favour

> of one's own bias. Still, it would be better if my response had been more

> sanguine.

>

> Erik

>

> P.S. s/publically/publicly (Yep, spellchecking in Vim in Mutt is OK

> with that. Caveat: I use a British

> dictionary. Haven't checked for possible USA

> divergent spelling.)

 

Reply | Threaded
Open this post in threaded view
|

Shell game? was Re: pmount could perhaps be of greater utility?

David Wright-3
In reply to this post by David-2
On Tue 07 May 2019 at 10:12:10 (+1000), David wrote:

> On Mon, 6 May 2019 at 23:53, Erik Christiansen <[hidden email]> wrote:
> > On 06.05.19 09:03, Greg Wooledge wrote:
> > > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> > > > Quoting Erik Christiansen (2019-05-04 08:43:53)
>
> > > > >      pmount $1 `e2label $1`
>
> > > and is using the ancient deprecated command substitution syntax (which
> > > will work in this case, but is not a good habit).
>
> > That does appear to remain opinion. The venerably traditional syntax is
> > still fully legal supported bash syntax, e.g.:
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
> >
> > The recent (late last century, IIRC) introduction of the $(...)
> > alternative syntax has admittedly brought newer *nix users who know
> > nothing else, and so delude themselves that there is nothing else. That
> > is a misapprehension. To each, his own, especially amongst adequately
> > equivalent alternatives.
>
> Hi Erik
>
> Maybe you would enjoy answering this question then?
> https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
>
> Because apparently no-one else has, hehe :D
My take on this problem goes as follows.

B is easy. man bash says "When the old-style backquote form of
substitution is used, backslash retains its literal meaning except
when followed by $, `, or \." So the \\ in B's inner echo becomes
\ in the outer echo. BB shows the result of running the outer echo
on the substitution made in B.

A is tricky, mainly because of the middle Quotation Mark¹. So the first
thing I would do is substitute a benign character, like x. The result
of that substitution is shown at J. Work with that, and then change x
back to Quotation Mark at the end.

So K runs the inner echo and shows the result. L then runs the outer
echo on that result (leaving out the [] brackets). Because \x is
meaningless in double quotes, it survives the outer echo untouched.

Now put back the Quotation Mark in place of x. man bash says "A double
quote may be quoted within double quotes by preceding it with a
backslash." And that's what we've got in M.

Now working outwards, I've added the [] brackets at LL and MM, where
they play no role. Finally the outer double quotes: because they pair
up with the double quotes from L, that leaves the \x exposed to the
outer echo and it becomes just x.

Who processed the \" into " in A? The outer echo (or, if you like, the
shell handing the arguments to the outer echo).

Over to Greg for checking.

¹ Quotation Mark rather than double quote because it never plays the
role of an active double quote as far as bash is concerned.

Cheers,
David.

bash-exercise (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Netiquette [Was: Re: pmount could perhaps be of greater utility?

Erik Christiansen
In reply to this post by rhkramer
On 07.05.19 09:05, [hidden email] wrote:
> So, I'll use "publicly" -- I was going to do that, but it just seemed wrong at
> the time ;-)

It seems harder to remember uncommon spelling now than when I was
younger, and until the spellchecker disagreed, I'd gone with your
spelling - it's more consistent. But then English isn't famous for that.

Erik

Reply | Threaded
Open this post in threaded view
|

Re: Shell game? was Re: pmount could perhaps be of greater utility?

KHMan
In reply to this post by David Wright-3
> On Tue 07 May 2019 at 10:12:10 (+1000), David wrote:
>> On Mon, 6 May 2019 at 23:53, Erik Christiansen wrote:
>> > On 06.05.19 09:03, Greg Wooledge wrote:
>> > > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
[snipped all]
>> Hi Erik
>>
>> Maybe you would enjoy answering this question then?
>> https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
>>
>> Because apparently no-one else has, hehe :D

Hi everyone, I'm the poster of the above query and I have just
subscribed here. Replying via the web link so if there is any
discussion, list thread won't break (hopefully).


> My take on this problem goes as follows.
>
> B is easy. man bash says "When the old-style backquote form of
> substitution is used, backslash retains its literal meaning except
> when followed by $, `, or \." So the \\ in B's inner echo becomes
> \ in the outer echo. BB shows the result of running the outer echo
> on the substitution made in B.
>
> A is tricky, mainly because of the middle Quotation Mark¹. So the first
> thing I would do is substitute a benign character, like x. The result
> of that substitution is shown at J. Work with that, and then change x
> back to Quotation Mark at the end.
>
> So K runs the inner echo and shows the result. L then runs the outer
> echo on that result (leaving out the [] brackets). Because \x is
> meaningless in double quotes, it survives the outer echo untouched.

Running the result of a command execution and allowing the result
to control delimiters, dropping out of the string? Now that gives
me the jeebies, security-wise. :-)

If you try to encapsulate the \" in a separate script file, then
it appears the above does not occur. Try this:

test.sh:
#/bin/bash
echo \"

$ echo "`./test.sh \\"`"
"

The " returned by test.sh doesn't close anything. \\" is passed as
argument to test.sh (I guess as \") and disappears. Unless echo as
a built-in (is it?) behaves differently. Still, the power to
control the parent's delimiters seems unlikely, IMHO.


I have since been studying the bash sources, and posted another
query yesterday, see:

http://lists.gnu.org/archive/html/help-bash/2019-05/msg00006.html

To summarize, consider our usual examples:
echo "[` echo \" \\" \" `]" A            # [ " ] A
echo "[` echo \" \\x \" `]" J            # [ \x ] J

Here's a theory: Inside the inner backquotes, \" gets escaped into
" because token processing sees the current delimiter as ". (But
matched pair processing sees the inner delimiters as ``.) The \\"
becomes \" and the \\x becomes \x. The inner commands are then run as:

echo " \" "
echo " \x "

giving the expected result. When entering the matched pair
processing function for the inner ``, the delimiter stack was not
updated, so the token function still sees the current delimiter as
the outer one, which is ".

This is based on what I have studied in the sources, and it
doesn't make any sense to me from a syntax point-of-view, so I
hope I can eventually get a useful and definitive answer from the
bash maintainers.


> Now put back the Quotation Mark in place of x. man bash says "A double
> quote may be quoted within double quotes by preceding it with a
> backslash." And that's what we've got in M.
>
> Now working outwards, I've added the [] brackets at LL and MM, where
> they play no role. Finally the outer double quotes: because they pair
> up with the double quotes from L, that leaves the \x exposed to the
> outer echo and it becomes just x.
>
> Who processed the \" into " in A? The outer echo (or, if you like, the
> shell handing the arguments to the outer echo).
>
> Over to Greg for checking.
>
> ¹ Quotation Mark rather than double quote because it never plays the
> role of an active double quote as far as bash is concerned.


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia

Reply | Threaded
Open this post in threaded view
|

Re: Shell game? was Re: pmount could perhaps be of greater utility?

David Wright-3
On Wed 08 May 2019 at 14:08:03 (+0800), KHMan wrote:
> > On Tue 07 May 2019 at 10:12:10 (+1000), David wrote:
> > > On Mon, 6 May 2019 at 23:53, Erik Christiansen wrote:
> > > > On 06.05.19 09:03, Greg Wooledge wrote:
> > > > > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
> [snipped all]
> > > Hi Erik
> > >
> > > Maybe you would enjoy answering this question then?
> > > https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html

> Running the result of a command execution and allowing the result to
> control delimiters, dropping out of the string? Now that gives me the
> jeebies, security-wise. :-)

I think you can heave a sigh of relief as I think I can show that's
not happening after all. The trick is to add   set -x   to the top
of the script (and I've set -v as well). It does appear (I think)
that the contents of the backquotes are interpreted earlier than
my working showed:

$ bash bash-bit
echo
+ echo

echo "[` echo \" \x \\x \\\x \\\\x \\" \\\" \" `]"
++ echo ' \x \x \x \x " " '
+ echo '[ \x \x \x \x " " ]'
[ \x \x \x \x " " ]
echo
+ echo

echo "[` echo \" \\" \\\" \\\\" \" `]"
bash-bit: command substitution: line 6: unexpected EOF while looking for matching `"'
bash-bit: command substitution: line 7: syntax error: unexpected end of file
+ echo '[]'
[]
echo
+ echo

#
$

But I'm not sure how to distinguish the order of the interpretation
of \\ and \" in the above.

> I have since been studying the bash sources, and posted another query
> yesterday, see:
>
> http://lists.gnu.org/archive/html/help-bash/2019-05/msg00006.html
>
> To summarize, consider our usual examples:
> echo "[` echo \" \\" \" `]" A            # [ " ] A
> echo "[` echo \" \\x \" `]" J            # [ \x ] J
>
> Here's a theory: Inside the inner backquotes, \" gets escaped into "
> because token processing sees the current delimiter as ". (But matched
> pair processing sees the inner delimiters as ``.) The \\" becomes \"
> and the \\x becomes \x. The inner commands are then run as:
>
> echo " \" "
> echo " \x "
I follow that. Unfortunately, set -x appears not to show the raw line
in that state, but interprets those outer double quotes and then
reports the line in its own single quotes.

> giving the expected result. When entering the matched pair processing
> function for the inner ``, the delimiter stack was not updated, so the
> token function still sees the current delimiter as the outer one,
> which is ".

So again it appears to involve the order of interpretation.

> This is based on what I have studied in the sources, and it doesn't
> make any sense to me from a syntax point-of-view, so I hope I can
> eventually get a useful and definitive answer from the bash
> maintainers.

Is backquote deprecated yet? :)

I saw Greg's followup to your new post; it seems mainly aimed at
outlawing overlapping strings and allowing only nested ones.
I guess, then, that that does prevent delimiting a string by a
quote from one level paired with one "dropping out of" (returned by)
the inner command.

Cheers,
David.

bash-bit (127 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Shell game? was Re: pmount could perhaps be of greater utility?

KHMan
On 5/9/2019 12:34 AM, David Wright wrote:

> On Wed 08 May 2019 at 14:08:03 (+0800), KHMan wrote:
>>> On Tue 07 May 2019 at 10:12:10 (+1000), David wrote:
>>>> On Mon, 6 May 2019 at 23:53, Erik Christiansen wrote:
>>>>> On 06.05.19 09:03, Greg Wooledge wrote:
>>>>>> On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote:
>> [snipped all]
>>>> Hi Erik
>>>>
>>>> Maybe you would enjoy answering this question then?
>>>> https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
>
>> Running the result of a command execution and allowing the result to
>> control delimiters, dropping out of the string? Now that gives me the
>> jeebies, security-wise. :-)
>
> I think you can heave a sigh of relief as I think I can show that's
> not happening after all. The trick is to add   set -x   to the top
> of the script (and I've set -v as well). It does appear (I think)
> that the contents of the backquotes are interpreted earlier than
> my working showed:
[snip]

Good tip, set -x is useful. I only know simple bash scripting. I
am actually doing this to fix shell code syntax highlighting for
the Scintilla edit control (Geany, Notepad++, SciTE, etc.) -- for
this one I want to get to the bottom of this rather than implement
its behaviour without fully understanding _why_.

[snip]
> But I'm not sure how to distinguish the order of the interpretation
> of \\ and \" in the above.

You need 5 backslashes to get \\x, I was trying such snippets
earlier in the week:

$ echo "[` echo \" \\\\\x \" `]"
++ echo ' \\x '
+ echo '[ \\x ]'
[ \\x ]

Going by my theory below, the inner `` string would be read as:
  echo " \\\x "
where \\ -> \ and \" -> ". Then it is executed, and there is
another \\ -> \ due to the "", so when the "" string is translated
into a literal string, it becomes:
  echo ' \\x '
and the rest follows.

For double quotes:

$ echo "[` echo \" \\" \" `]"
++ echo ' " '
+ echo '[ " ]'
[ " ]

The inner `` string is first read as:
  echo " \" "
because of \\ -> \ and the " in the \\" becomes just a character
since it is not an ending delimiter for the `` inner string. When
executed, the " \" " string would be equivalent to the ' " '
literal string. The result follows.

If we try \\\":

$ echo "[` echo \" \\\" \" `]"
++ echo ' " '
+ echo '[ " ]'
[ " ]

Here, the inner `` string is first read as:
  echo " \" "
where \\ -> \ and \" -> ". When executed the " \" " string would
again be equivalent to the ' " ' literal string. Final result is
the same.

This would however cause an error:

$ echo "[` echo \" \\\\" \" `]"

The inner `` string is first read as:
  echo " \\" "
because of two \\ -> \ escapes. Then the " \\" " becomes ' \' plus
an extra ".

Five backslashes will fail too, it still results in the inner string:
  echo " \\" "

Six backslashes work. It will give the interim of:
  echo " \\\" "
where " \\\" " end up as ' \" ' and the result is as predicted.


>> I have since been studying the bash sources, and posted another query
>> yesterday, see:
>>
>> http://lists.gnu.org/archive/html/help-bash/2019-05/msg00006.html
>>
>> To summarize, consider our usual examples:
>> echo "[` echo \" \\" \" `]" A            # [ " ] A
>> echo "[` echo \" \\x \" `]" J            # [ \x ] J
>>
>> Here's a theory: Inside the inner backquotes, \" gets escaped into "
>> because token processing sees the current delimiter as ". (But matched
>> pair processing sees the inner delimiters as ``.) The \\" becomes \"
>> and the \\x becomes \x. The inner commands are then run as:
>>
>> echo " \" "
>> echo " \x "
>
> I follow that. Unfortunately, set -x appears not to show the raw line
> in that state, but interprets those outer double quotes and then
> reports the line in its own single quotes.
>
>> giving the expected result. When entering the matched pair processing
>> function for the inner ``, the delimiter stack was not updated, so the
>> token function still sees the current delimiter as the outer one,
>> which is ".
>
> So again it appears to involve the order of interpretation.

If you study the sources, bash does make string parsing calls
recursively as expected for this kind of thing. The anomaly I see
is at parse.y[3734] for bash-5.0. A call is made to parse the
inner `` string while currently parsing a "" string, so it is
nesting, _but_ the delimiter stack is not updated.

The read_token_word function uses the delimiter stack to determine
escaping (see parse.y[4942] and parse.y[4961]) so inside that
inner `` string, it is running the escape behaviour for ""
strings. So I am trying to find out if it is intentional. Is the
inner `` supposed to be semantically part of the outer "" string?
If so, the additional level of escaping due to execution of the ``
inner string serves to confuse matters a lot.


>> This is based on what I have studied in the sources, and it doesn't
>> make any sense to me from a syntax point-of-view, so I hope I can
>> eventually get a useful and definitive answer from the bash
>> maintainers.
>
> Is backquote deprecated yet? :)

Doesn't matter, since editor users will hit this scenario, then
the downstream editors will point their fingers at Scintilla and
bug tickets will be filed with the Scintilla project. So I am
still planning to get some kind of answer from the bash folks.


> I saw Greg's followup to your new post; it seems mainly aimed at
> outlawing overlapping strings and allowing only nested ones.
> I guess, then, that that does prevent delimiting a string by a
> quote from one level paired with one "dropping out of" (returned by)
> the inner command.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Eric S Fraga
In reply to this post by Erik Christiansen
On Saturday,  4 May 2019 at 16:43, Erik Christiansen wrote:
>  To provide that convenient automation, I use:
>
>  $ which lmount
>  lmount is a function
>  lmount ()
>  {
>      pmount $1 `e2label $1`
>  }

This is nice; is there an equivalent for FAT file systems?  Most of the
devices I mount using pmount are sd cards (cameras etc.).

Thanks.
--
Eric S Fraga via Emacs 27.0.50 & org 9.2.3 on Debian buster/sid

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Erik Christiansen
On 11.05.19 14:38, Eric S Fraga wrote:

> On Saturday,  4 May 2019 at 16:43, Erik Christiansen wrote:
> >  To provide that convenient automation, I use:
> >
> >  $ which lmount
> >  lmount is a function
> >  lmount ()
> >  {
> >      pmount $1 `e2label $1`
> >  }
>
> This is nice; is there an equivalent for FAT file systems?  Most of the
> devices I mount using pmount are sd cards (cameras etc.).

Pmount is just a wrapper around the standard mount program, and that
will try to guess the fs type if not specified in the invocation - as
above. That manages ext2 and ext3 without assistance, but ... Ah, yes,
with a vfat stick it gives:

$ lmount /dev/sdb1
e2label: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

And "tune2fs -l /dev/sdb1" says the same. Quite what the automounter
does to overcome that, I haven't yet figured out. A quick rewrite of
the tiny wrapper wrapper does improve matters somewhat:

lmount () {                         # Mount a USB stick at /media/read_stick_label
   if [ mp=`e2label $1` ] ; then    # if e2label can grok the label.
      pmount $1 $mp
   else                             # When that fails, TRY TO
      pmount -t vfat $1 vfat        # use fs type as mountpoint, for now.
   fi
}

mounts vfat OK, but the "label" argument, now third, is ignored despite
being compliant with the manpage. So it falls back to mounting on
/media/sdb1 in a most wilful manner:

/dev/sdb1 on /media/sdb1 type vfat
(rw,nosuid,nodev,noexec,relatime,uid=1000,gid=1000,fmask=0177,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,quiet,utf8,errors=remount-ro)

Either I'm not holding my mouth right, or that looks like a bug.

> Thanks.

We're not home yet.

Erik

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Eric S Fraga
On Sunday, 12 May 2019 at 17:52, Erik Christiansen wrote:
> On 11.05.19 14:38, Eric S Fraga wrote:
>> This is nice; is there an equivalent for FAT file systems?  Most of the
>> devices I mount using pmount are sd cards (cameras etc.).
>
> Pmount is just a wrapper around the standard mount program, and that
> will try to guess the fs type if not specified in the invocation - as
> above. That manages ext2 and ext3 without assistance, but ... Ah, yes,
> with a vfat stick it gives:

Sorry, I should have been more explicit.  I use pmount all the
time.  Works fine.  What I was looking for was an equivalent of e2label
for vfat, if that even makes any sense.

--
Eric S Fraga via Emacs 27.0.50 & org 9.2.3 on Debian buster/sid

Reply | Threaded
Open this post in threaded view
|

Re: pmount could perhaps be of greater utility?

Eric S Fraga
In reply to this post by Erik Christiansen
On Sunday, 12 May 2019 at 17:52, Erik Christiansen wrote:

[...]

> mounts vfat OK, but the "label" argument, now third, is ignored despite
> being compliant with the manpage. So it falls back to mounting on
> /media/sdb1 in a most wilful manner:

And I probably should have read your post more carefully before
replying.  Even if there is an equivalent to e2label for vfat, it
wouldn't be of much use from what you say here.

No worries!

--
Eric S Fraga via Emacs 27.0.50 & org 9.2.3 on Debian buster/sid

12