Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208100 > unrolled thread

pmount could perhaps be of greater utility?

Back to article view | Back to linux.debian.user

Contents

  pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-04 08:50 +0200
    Re: pmount could perhaps be of greater utility? Jonas Smedegaard <jonas@jones.dk> - 2019-05-04 13:50 +0200
      Re: pmount could perhaps be of greater utility? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-06 15:10 +0200
        Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-06 16:00 +0200
          Re: pmount could perhaps be of greater utility? David <bouncingcats@gmail.com> - 2019-05-07 02:20 +0200
            Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-07 06:10 +0200
              Netiquette [Was: Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-07 14:50 +0200
                Re: Netiquette [Was: Re: pmount could perhaps be of greater utility? rhkramer@gmail.com - 2019-05-07 15:10 +0200
                  Re: Netiquette [Was: Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-08 05:30 +0200
            Re: pmount could perhaps be of greater utility? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-07 14:20 +0200
              Re: pmount could perhaps be of greater utility? David <bouncingcats@gmail.com> - 2019-05-19 07:10 +0200
            Shell game? was Re: pmount could perhaps be of greater utility? David Wright <deblis@lionunicorn.co.uk> - 2019-05-07 21:00 +0200
              Re: Shell game? was Re: pmount could perhaps be of greater utility? KHMan <keinhong@gmail.com> - 2019-05-08 08:10 +0200
                Re: Shell game? was Re: pmount could perhaps be of greater utility? David Wright <deblis@lionunicorn.co.uk> - 2019-05-08 18:40 +0200
                  Re: Shell game? was Re: pmount could perhaps be of greater utility? KHMan <keinhong@gmail.com> - 2019-05-08 20:10 +0200
      Remove nautilus to stop automounts? [Was: Re: pmount could perhaps  be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-07 13:40 +0200
        Re: Remove nautilus to stop automounts? [Was: Re: pmount could  perhaps be of greater utility? Brian <ad44@cityscape.co.uk> - 2019-05-07 14:00 +0200
    Re: pmount could perhaps be of greater utility? Eric S Fraga <e.fraga@ucl.ac.uk> - 2019-05-11 15:40 +0200
      Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-12 10:00 +0200
        Re: pmount could perhaps be of greater utility? Eric S Fraga <e.fraga@ucl.ac.uk> - 2019-05-12 14:50 +0200
          Re: pmount could perhaps be of greater utility? Erik Christiansen <dvalin@internode.on.net> - 2019-05-12 15:40 +0200
            Re: pmount could perhaps be of greater utility? Eric S Fraga <e.fraga@ucl.ac.uk> - 2019-05-12 21:30 +0200
            Re: pmount could perhaps be of greater utility? David Wright <deblis@lionunicorn.co.uk> - 2019-05-15 06:40 +0200
        Re: pmount could perhaps be of greater utility? Eric S Fraga <e.fraga@ucl.ac.uk> - 2019-05-12 15:00 +0200
        Re: pmount could perhaps be of greater utility? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-13 15:10 +0200

Page 1 of 2  [1] 2  Next page →

#208100 — pmount could perhaps be of greater utility?

>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

[toc] | [next] | [standalone]

#208111

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#208270

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

[toc] | [prev] | [next] | [standalone]

#208276

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

[toc] | [prev] | [next] | [standalone]

#208332

On Mon, 6 May 2019 at 23:53, Erik Christiansen <dvalin@internode.on.net> 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

[toc] | [prev] | [next] | [standalone]

#208334

On 07.05.19 10:12, David wrote:
> On Mon, 6 May 2019 at 23:53, Erik Christiansen <dvalin@internode.on.net> 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

[toc] | [prev] | [next] | [standalone]

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

On 07.05.19 07:38, rhkramer@gmail.com 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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

On 07.05.19 09:05, rhkramer@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#208352

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

[toc] | [prev] | [next] | [standalone]

#208828

On Tue, 7 May 2019 at 22:15, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> 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?

I did. I encourage people to read everything you write on shells.
Your dedication to promoting good practice is astounding.

I apologise for the slow reply, but at the moment I have insufficient
time to keep up with messages here, especially ones that run off
track.

I linked to that thread because I thought it (including your answer)
was a useful addition to the discussion in this one.

I noticed my message later described as a "shot across the bows".
That phrase as I understand it describes a violent threat of physical harm
intended to create fear that will cause another party to change their
behaviour.

On the contrary. I was attempting to add information and context in
a friendly and light-hearted manner (there was a "Hi", a "hehe" and
a ":D") but it seems that wasn't enough to make the intention clear.

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

I know. I am grateful for his previous work to provide syntax highlighting.
Although lately I am starting to prefer vim, depending on the task.

The code there is ridiculous, except as an example for a parsing
question which I think was its purpose. I thank KHMan for his completely
unselfish effort to write editor code that tries to correctly deal with whatever
crap other people might throw into it. I suppose a solution could for
unparseable code to remain uncoloured. It can be very distracting when
syntax highlighting is incorrect.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Tue 07 May 2019 at 10:12:10 (+1000), David wrote:
> On Mon, 6 May 2019 at 23:53, Erik Christiansen <dvalin@internode.on.net> 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.

[toc] | [prev] | [next] | [standalone]

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

> 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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

#208572

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

[toc] | [prev] | [next] | [standalone]

#208592

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

[toc] | [prev] | [next] | [standalone]

#208596

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web