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

Groups > comp.sys.mac.system > #133841 > unrolled thread

Wildcard and ls

Back to article view | Back to comp.sys.mac.system

Contents

  Wildcard and ls JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-07-28 23:07 -0400
    Re: Wildcard and ls Arlen Holder <arlenholder@newmachine.com> - 2020-07-29 05:06 +0000
      Re: Wildcard and ls nospam <nospam@nospam.invalid> - 2020-07-29 01:35 -0400
        Re: Wildcard and ls Arlen Holder <arlenholder@newmachine.com> - 2020-07-29 12:41 +0000
      Re: Wildcard and ls Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2020-07-29 08:04 +0200
        Re: Wildcard and ls Arlen Holder <arlenholder@newmachine.com> - 2020-07-29 12:40 +0000
          Re: Wildcard and ls Arlen Holder <arlenholder@newmachine.com> - 2020-07-29 14:21 +0000
    Re: Wildcard and ls Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2020-07-29 08:00 +0200
      Re: Wildcard and ls JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-07-29 03:15 -0400
        Re: Wildcard and ls Lewis <g.kreme@gmail.com.dontsendmecopies> - 2020-07-29 09:49 +0000
          Re: Wildcard and ls Jolly Roger <jollyroger@pobox.com> - 2020-07-29 18:45 +0000
            Re: Wildcard and ls Arlen Holder <arlenholder@newmachine.com> - 2020-07-30 02:39 +0000
        Re: Wildcard and ls Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2020-07-30 08:03 +0200
          Re: Wildcard and ls Siri Cruise <chine.bleu@yahoo.com> - 2020-07-30 03:50 -0700
            Re: Wildcard and ls Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2020-07-30 13:40 +0200
            Re: Wildcard and ls Lewis <g.kreme@gmail.com.dontsendmecopies> - 2020-07-30 11:49 +0000
          Re: Wildcard and ls Lewis <g.kreme@gmail.com.dontsendmecopies> - 2020-07-30 11:43 +0000
          Re: Wildcard and ls Barry Margolin <barmar@alum.mit.edu> - 2020-07-30 10:26 -0400
            Re: Wildcard and ls Lewis <g.kreme@gmail.com.dontsendmecopies> - 2020-07-30 14:55 +0000
        Re: Wildcard and ls Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2020-07-30 08:23 +0200

#133841 — Wildcard and ls

Something I am not seeing here.


> velo:opl $  sudo ls /Volumes/DMA3/Backups/Backup2/jfmezei/opl/

> airconv.opl     dist.opl        mime.opl        telnet.opl      test4.opl       waypoint.opl
> almanac.opl     ebhedit.opl     mission.opl     telnet2.opl     tracksav.opl    waysave.opl
> almarec.opl     getworld.opl    program.opl     test.opl        tracksnd.opl
> bikelog.opl     gpscomm.opl     route.opl       test2.opl       triplog.opl
> cameron.opl     latlon.opl      rttelnet.opl    test3.opl       wayedit.opl
> 
> velo:opl $  sudo ls /Volumes/DMA3/Backups/Backup2/jfmezei/opl/*.opl

> ls: /Volumes/DMA3/Backups/Backup2/jfmezei/opl/*.opl: No such file or directory


sudo is needed because this old backup directory structure not public to me.

Any explanation on why the ls works, but the ls *.opl doesn't ?
What I am obviously not seeing ?



I did a

sudo bash
cd /Volumes/DMA3/Backups/Backup2/jfmezei/opl
ls *.opl
and this worked fine

[toc] | [next] | [standalone]

#133844

On Tue, 28 Jul 2020 23:07:43 -0400, JF Mezei wrote:

> Any explanation on why the ls works, but the ls *.opl doesn't ?

I don't use the Mac unless I'm forced to at gunpoint (which happens mostly
in educational and friend environments), where I'll just state the basics,
which are, as I recall, on "normal" Linux, offhand... 
o asterisk matches zero or more occurrences of characters
o question mark matches zero or one occurrence of a character
o dot matches one or more occurrences of a character (newline excepted)
-- 
Different interpreters of regular expressions may very well vary.

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

#133845

In article <rfr053$cpb$1@news.mixmin.net>, Arlen Holder
<arlenholder@newmachine.com> wrote:

> 
> I don't use the Mac unless I'm forced to at gunpoint (which happens mostly
> in educational and friend environments),

ideally one that's fully loaded with the safety off and held by someone
who has uncontrollable muscle tremors in their fingers.

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

#133857

On Wed, 29 Jul 2020 01:35:39 -0400, nospam wrote:

> ideally one that's fully loaded with the safety off and held by someone
> who has uncontrollable muscle tremors in their fingers.

The key difference between you and normal people, nospam...
o Is you never post with purposefully helpful intent.
-- 
You post as a child.

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

#133849

On 29/07/2020 07:06, Arlen Holder wrote:
> On Tue, 28 Jul 2020 23:07:43 -0400, JF Mezei wrote:
> 
>> Any explanation on why the ls works, but the ls *.opl doesn't ?
> 
> I don't use the Mac unless I'm forced to at gunpoint (which happens mostly
> in educational and friend environments), 

Do your friends often hold you at gunpoint? I would consider changing 
friends if I were you.

> where I'll just state the basics,
> which are, as I recall, on "normal" Linux, offhand...
> o asterisk matches zero or more occurrences of characters
> o question mark matches zero or one occurrence of a character
> o dot matches one or more occurrences of a character (newline excepted)
> 

JF Mezei would run into exactly the same problem under Linux or any Unix.

-- 
Chemical engineers do it in packed beds.

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

#133856

On Wed, 29 Jul 2020 08:04:29 +0200, Krzysztof Mitko wrote:



Hi Krzysztof Mitko,
I appreciate that you strove to help JF Mezei, which is the important
thing.

> Do your friends often hold you at gunpoint? 
> I would consider changing friends if I were you.

Put it this way... sometimes they ask me to change their tires for them,
and sometimes, those tires are on a sedan, which is normal in every way,
and which is easy to do, but sometimes, rarely, but sometimes, those tires
are on a truck, which is a bitch to change their tire for them at home.\

That's my assessment of the difference between a normal consumer operating
system, and the Mac, albeit, I avoid the Mac as much as I can just as I
avoid mounting and balancing truck tires at home when I can.

o Questions about mounting & balancing new LT tires on new steel rims 
  at home (match mounting marks, red dots, yellow dots, & spacers)
<https://groups.google.com/topic/rec.autos.tech/J5-7TxdDpBw>

> JF Mezei would run into exactly the same problem under Linux or any Unix.

Sometimes, rarely, but sometimes, not all tires mount the same way... 
o Perhaps not all interpreters interpret regexp the same way... (dunno)

My point to JF Mezei was that I didn't test it out on the Mac, so I
caveated my description of the meaning of the regular expressions from
memory (as I didn't test it out on a Mac which normally I would do if I had
the hardware).

To the point that regular expressions are regular expressions, I'm not so
sure all interpreters are the same, but if the Mac handles it like, oh,
say, Ubuntu, I'm fine with that assessment of yours since you're trying to
be helpful.

The point was to try to be helpful to JF Mezei, and I think you were.
-- 
Thanks for being an adult in your response, which is lacking on this ng.

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

#133859

On Wed, 29 Jul 2020 12:40:59 -0000 (UTC), Arlen Holder wrote:

> o Questions about mounting & balancing new LT tires on new steel rims 
>   at home (match mounting marks, red dots, yellow dots, & spacers)
> <https://groups.google.com/topic/rec.autos.tech/J5-7TxdDpBw>

Oooooooooops. There was a typo in the URL.

o Questions about mounting & balancing new LT tires on new steel rims 
  at home (match mounting marks, red dots, yellow dots, & spacers)
<https://groups.google.com/forum/#!topic/rec.autos.tech/J5-7TxdDpBw>

To Krzysztof Mitko's credit, he attempted to help JF Mezei
o As did I.

To further answer his question, the point of the tire example is that I
avoid the Mac at all costs simply because it's not as easy to use nor as
functional for a huge variety of reasons, as is Windows or Ubuntu IMHO.

Yet, sometimes, when I help people, or when I'm in a school environment,
I'm forced to use the Mac, which is why I caveated what I said when I
strove to purposefully help JF Mezei, since I am wont to test things before
suggesting them so that I'm sure they work.

I do find interesting though, that the known apologists, nospam (Type I)
and Lewis (Type III) can only post proving they own the minds of children.

Apologists like nospam & Lewis have always been what ruins this newsgroup.
-- 
It's shocking how the apologists always prove to own the mind of a child.

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

#133848

On 29/07/2020 05:07, JF Mezei wrote:
> Something I am not seeing here.
> 
> 
>> velo:opl $  sudo ls /Volumes/DMA3/Backups/Backup2/jfmezei/opl/
> 
>> airconv.opl     dist.opl        mime.opl        telnet.opl      test4.opl       waypoint.opl
>> almanac.opl     ebhedit.opl     mission.opl     telnet2.opl     tracksav.opl    waysave.opl
>> almarec.opl     getworld.opl    program.opl     test.opl        tracksnd.opl
>> bikelog.opl     gpscomm.opl     route.opl       test2.opl       triplog.opl
>> cameron.opl     latlon.opl      rttelnet.opl    test3.opl       wayedit.opl
>>
>> velo:opl $  sudo ls /Volumes/DMA3/Backups/Backup2/jfmezei/opl/*.opl
> 
>> ls: /Volumes/DMA3/Backups/Backup2/jfmezei/opl/*.opl: No such file or directory
> 
> 
> sudo is needed because this old backup directory structure not public to me.

And that's the problem. Your shell is trying to expand the * wildcard 
before sudo is executed and fails because lack of permissions.

> Any explanation on why the ls works, but the ls *.opl doesn't ?
> What I am obviously not seeing ?
> 
> 
> 
> I did a
> 
> sudo bash
> cd /Volumes/DMA3/Backups/Backup2/jfmezei/opl
> ls *.opl
> and this worked fine
> 
> 
> 


-- 
Chemical engineers do it in packed beds.

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

#133851

On 2020-07-29 02:00, Krzysztof Mitko wrote:

> And that's the problem. Your shell is trying to expand the * wildcard 
> before sudo is executed and fails because lack of permissions.


Thanks. That explains the behaviour. I had though that ls did its own
wildcarding but in this case, I guess it is sudo that triggers the
expansion.

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

#133855

In message <tm9UG.96980$r25.75717@fx08.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2020-07-29 02:00, Krzysztof Mitko wrote:

>> And that's the problem. Your shell is trying to expand the * wildcard 
>> before sudo is executed and fails because lack of permissions.


> Thanks. That explains the behaviour. I had though that ls did its own
> wildcarding but in this case, I guess it is sudo that triggers the
> expansion.

No, that is not correct and that is not what Kryzsztof said.

Please re-read for comprehension. As many times as it takes.

I would guess it will take you at least six times, or three months,
whichever comes first.

-- 
'Do you know what they call a sausage-in-a-bun in Quirm?' 'No?' said
	Mr Tulip 'They called it le sausage-in-le-bun.' 'What, in a --ing
	foreign language? You're --ing kidding!'

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

#133866

On 2020-07-29, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <tm9UG.96980$r25.75717@fx08.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> On 2020-07-29 02:00, Krzysztof Mitko wrote:
>
>>> And that's the problem. Your shell is trying to expand the * wildcard 
>>> before sudo is executed and fails because lack of permissions.
>
>
>> Thanks. That explains the behaviour. I had though that ls did its own
>> wildcarding but in this case, I guess it is sudo that triggers the
>> expansion.
>
> No, that is not correct and that is not what Kryzsztof said.
>
> Please re-read for comprehension. As many times as it takes.
>
> I would guess it will take you at least six times, or three months,
> whichever comes first.

Nah. He'll never completely understand.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#133889

On 29 Jul 2020 18:45:33 GMT, Jolly Roger wrote:

>> Lewis wrote:
>> I would guess it will take you at least six times, or three months,
>> whichever comes first.
> 
> Nah. He'll never completely understand.

Regarding JF Mezei's valid query:
o *Wildcard and ls*
<https://groups.google.com/forum/#!topic/comp.sys.mac.system/5NiAyL-k79o>

I love when Jolly Roger & Lewis post because they always prove my point
o That what ruins this newsgroup, is simply that these apologists exist.

As did nospam's always childish purposefully unhelpful retorts on JF Mezei.

See also:
o *Clear evidence that the real factual problem on Apple Usenet newsgroups - is simply that apologists exist*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/mQsBECSbICw>
-- 
Neither Jolly Roger nor Lewis ever posted with purposefully helpful intent.

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

#133891

On 29/07/2020 09:15, JF Mezei wrote:
> On 2020-07-29 02:00, Krzysztof Mitko wrote:
> 
>> And that's the problem. Your shell is trying to expand the * wildcard
>> before sudo is executed and fails because lack of permissions.
> 
> 
> Thanks. That explains the behaviour. I had though that ls did its own
> wildcarding but in this case, I guess it is sudo that triggers the
> expansion.
> 

Bash triggers the expansion, not sudo. If I recall it goes like this:

When you press enter, the shell (bash) reads the entire line and tries 
to interpret it. At this point, all your input is interpreted with your 
environment variables, permissions etc. It encounters first word, sudo, 
checks if it's internal command (if, while, for etc.) - it's not, so it 
looks up for a binary in your $PATH (not root's).

Then it sees "ls" and assumes it must be an argument for program "sudo".

Then is sees "/some/path/*" and, because it contains a wildcard, bash 
tries to expand it. But your privileges have not been risen to root at 
this point yet, so bash makes all the necessary system calls as user. 
Normally, it would expand "/some/path/*" to "/some/path/file1 
/some/path2" and the expanded arguments would be passed to "sudo". That 
is, bash would in the background change "sudo ls /some/path/*" to 
"/usr/bin/sudo ls /some/path/file1 /some/path/file2" - one program 
(/usr/bin/sudo) and three arguments (ls, /some/path/file1, 
/some/path/file2) [1]. But you, as user, don't have the permission to 
read the contents of /some/path, so system calls bash made to expand 
this wildcard return error.

At that moment, the behaviour may vary[1]. In the most popular shells 
(sh, bash, zsh), regardless of which OS you use, when the wildcard 
expansion returns an error, the shell assumes you *literally* meant the 
file named /some/path/* and what is actually executed is "/usr/bin/sudo 
ls /some/path/*" (one program, two arguments). Then sudo elevates your 
priviledges and executes "ls /some/path/*" (one program, one argument, 
sudo does not expand wildcards on its own). The ls, now working as 
root's process, tries to open file "/some/path/*", but because this file 
doesn't exists, you get an error "no such file".

[1] - side note: there is a limit on how many arguments a program can 
take. If you run ls * in a directory with too many files you get an 
error exactly because bash expanded the wildcard to too many separate 
arguments

[2] - I *think* csh behaves differently here

-- 
Chemical engineers do it in packed beds.

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

#133893

In article <5f2262be$0$538$65785112@news.neostrada.pl>,
 Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> wrote:

> >> And that's the problem. Your shell is trying to expand the * wildcard
> >> before sudo is executed and fails because lack of permissions.
> > 
> > 
> > Thanks. That explains the behaviour. I had though that ls did its own
> > wildcarding but in this case, I guess it is sudo that triggers the
> > expansion.
> > 
> 
> Bash triggers the expansion, not sudo. If I recall it goes like this:

I can't try on other than macosx, but here sudo has a -s option 
to have sudo parse the command.

# ls r/*
ls: r/*: Permission denied
# sudo ls r/*
ls: r/*: No such file or directory
# sudo -s 'ls r/*'
r/a r/b
# sudo -s ls r/* 
r/a r/b


> [1] - side note: there is a limit on how many arguments a program can 
> take. If you run ls * in a directory with too many files you get an 
> error exactly because bash expanded the wildcard to too many separate 
> arguments

Which is something you can fudge around with find and xargs or 
-exec

# find . | xargs ls -ld

# find . -exec ls -ld '{}' \;

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
The first law of discordiamism: The more energy   This post         / \
to make order is nore energy made into entropy.   insults Islam.  Mohammed

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

#133895

On 30/07/2020 12:50, Siri Cruise wrote:
> In article <5f2262be$0$538$65785112@news.neostrada.pl>,
>   Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> wrote:
> 
>>>> And that's the problem. Your shell is trying to expand the * wildcard
>>>> before sudo is executed and fails because lack of permissions.
>>>
>>>
>>> Thanks. That explains the behaviour. I had though that ls did its own
>>> wildcarding but in this case, I guess it is sudo that triggers the
>>> expansion.
>>>
>>
>> Bash triggers the expansion, not sudo. If I recall it goes like this:
> 
> I can't try on other than macosx, but here sudo has a -s option
> to have sudo parse the command.
> 
> # ls r/*
> ls: r/*: Permission denied
> # sudo ls r/*
> ls: r/*: No such file or directory
> # sudo -s 'ls r/*'
> r/a r/b
> # sudo -s ls r/*
> r/a r/b

Thanks, I didn't know that - I've never bothered to read entire man sudo :).

>> [1] - side note: there is a limit on how many arguments a program can
>> take. If you run ls * in a directory with too many files you get an
>> error exactly because bash expanded the wildcard to too many separate
>> arguments
> 
> Which is something you can fudge around with find and xargs or
> -exec
> 
> # find . | xargs ls -ld

And if you except spaces in file names:

find . -print0 | xargs -0 ls -ld

> # find . -exec ls -ld '{}' \;

The \; means new separate ls process is launched for every file found.

find . -exec ls -ld {} +

When + is used, new ls process only starts if the maximum number of 
arguments is reached. It can speed things up if you want to execute 
something big.

-- 
Chemical engineers do it in packed beds.

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

#133897

In message <chine.bleu-69230D.03500830072020@reader.eternal-september.org> Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <5f2262be$0$538$65785112@news.neostrada.pl>,
>  Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> wrote:

>> >> And that's the problem. Your shell is trying to expand the * wildcard
>> >> before sudo is executed and fails because lack of permissions.
>> > 
>> > 
>> > Thanks. That explains the behaviour. I had though that ls did its own
>> > wildcarding but in this case, I guess it is sudo that triggers the
>> > expansion.
>> > 
>> 
>> Bash triggers the expansion, not sudo. If I recall it goes like this:

> I can't try on other than macosx, but here sudo has a -s option 
> to have sudo parse the command.

> # ls r/*
> ls: r/*: Permission denied
> # sudo ls r/*
> ls: r/*: No such file or directory
> # sudo -s 'ls r/*'
> r/a r/b
> # sudo -s ls r/* 
> r/a r/b

Yes, the -s flag tells sudo "open a shell to run the commands" and in
fact, `sudo -s` by itself will spawn a root permissioned interactive
shell.

 -s, --shell
	  Run the shell specified by the SHELL environment variable if it
      is set or the shell specified by the invoking user's password 
      database entry.  If a command is specified, it is passed to 
      the shell for execution via the shell's -c option.  If no 
      command is specified, an interactive shell is executed.  Note 
      that most shells behave differently when a command is specified
      as compared to an interactive session; consult the shell's 
      manual for details.

(again, nothing to do with macOS specifically)

-- 
WORDS IN THE HEART CANNOT BE TAKEN --Feet of Clay

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

#133896

In message <5f2262be$0$538$65785112@news.neostrada.pl> Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> wrote:
> On 29/07/2020 09:15, JF Mezei wrote:
>> On 2020-07-29 02:00, Krzysztof Mitko wrote:
>> 
>>> And that's the problem. Your shell is trying to expand the * wildcard
>>> before sudo is executed and fails because lack of permissions.
>> 
>> 
>> Thanks. That explains the behaviour. I had though that ls did its own
>> wildcarding but in this case, I guess it is sudo that triggers the
>> expansion.
>> 

> Bash triggers the expansion, not sudo.

exactly, it is why this also will not work:

sudo echo "this si a test" >> /etc/passwd

the >> is dealt with by the shell, bit by sudo, so you end up trying to
write text to a prividledged file without sudo permissions.

Also, this has nothing at all to do with macOS, this is how the unix
command line has always worked and the behavior is exactly the same on
Debian and FreeBSD.

> [2] - I *think* csh behaves differently here

It's possible, it's been decades since I used csh, but I am pretty sure
that tcsh behaved the same way ~20 yeas ago.


-- 
Hudd: 'I've just done this radio show where I never met any of the
	other actors and I didn't understand what any of it was about'
Moore: 'Ah, yes I expect that's the thing I'm in.'

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

#133904

In article <5f2262be$0$538$65785112@news.neostrada.pl>,
 Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> wrote:

> On 29/07/2020 09:15, JF Mezei wrote:
> > On 2020-07-29 02:00, Krzysztof Mitko wrote:
> > 
> >> And that's the problem. Your shell is trying to expand the * wildcard
> >> before sudo is executed and fails because lack of permissions.
> > 
> > 
> > Thanks. That explains the behaviour. I had though that ls did its own
> > wildcarding but in this case, I guess it is sudo that triggers the
> > expansion.
> > 
> 
> Bash triggers the expansion, not sudo. If I recall it goes like this:
> 
> When you press enter, the shell (bash) reads the entire line and tries 
> to interpret it. At this point, all your input is interpreted with your 
> environment variables, permissions etc. It encounters first word, sudo, 
> checks if it's internal command (if, while, for etc.) - it's not, so it 
> looks up for a binary in your $PATH (not root's).
> 
> Then it sees "ls" and assumes it must be an argument for program "sudo".
> 
> Then is sees "/some/path/*" and, because it contains a wildcard, bash 
> tries to expand it. 

That's not the actual order.

First the shell replaces all variables with their values.

Then it splits the resulting line into words.

Then it expands all the wildcards and command substitutions.

At this point it treats the first word as a command and the rest of the 
words as arguments.

This means you can even have a wildcard at the beginning that expands 
into the command followed by arguments, e.g.

foo* x y z

This will expand the wilcard, and treat the first file found (in 
lexicographic order) as the command and the remaining files as the first 
arguments. This can be useful if you remember that the command begins 
with "foo" but don't remember the whole name (although command 
completion will also work for that).

There are other steps I've skipped, like looking for environment 
variable settings. But the important point is that wildcard expansion is 
done BEFORE most other interpretation of the command.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

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

#133905

In message <barmar-D4E72B.10264130072020@reader.eternal-september.org> Barry Margolin <barmar@alum.mit.edu> wrote:
> This means you can even have a wildcard at the beginning that expands 
> into the command followed by arguments, e.g.

> foo* x y z

Hmm. Not in my szh it doesn't

$ gda*                                          
zsh: no matches found: gda*
$ gdate
Thu Jul 30 08:52:58 MDT 2020

> There are other steps I've skipped, like looking for environment 
> variable settings. But the important point is that wildcard expansion is 
> done BEFORE most other interpretation of the command.

Yep. And it is easy to forget that.

-- 
The universe doesn't much care if you tread on a butterfly. There are
	plenty more butterflies. Gods might note the fall of a sparrow
	but they don't make any effort to catch them. --Lords and Ladies

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

#133892

On 29/07/2020 09:15, JF Mezei wrote:
> On 2020-07-29 02:00, Krzysztof Mitko wrote:
> 
>> And that's the problem. Your shell is trying to expand the * wildcard
>> before sudo is executed and fails because lack of permissions.
> 
> 
> Thanks. That explains the behaviour. I had though that ls did its own
> wildcarding but in this case, I guess it is sudo that triggers the
> expansion.
> 

Bash triggers the expansion, not sudo. If I recall it goes like this:

When you press enter, the shell (bash) reads the entire line and tries 
to interpret it. At this point, all your input is interpreted with your 
environment variables, permissions etc. It encounters first word, sudo, 
checks if it's internal command (if, while, for etc.) - it's not, so it 
looks up for a binary in your $PATH (not root's).

Then it sees "ls" and assumes it must be an argument for program "sudo".

Then is sees "/some/path/*" and, because it contains a wildcard, bash 
tries to expand it. But your privileges have not been risen to root at 
this point yet, so bash makes all the necessary system calls as user. 
Normally, it would expand "/some/path/*" to "/some/path/file1 
/some/path/file2" and the expanded arguments would be passed to "sudo". 
That is, bash would in the background change "sudo ls /some/path/*" to 
"/usr/bin/sudo ls /some/path/file1 /some/path/file2" - one program 
(/usr/bin/sudo) and three arguments (ls, /some/path/file1, 
/some/path/file2) [1]. But you, as user, don't have the permission to 
read the contents of /some/path, so system calls bash made to expand 
this wildcard return error.

At that moment, the behaviour may vary[2]. In the most popular shells 
(sh, bash, zsh), regardless of which OS you use, when the wildcard 
expansion returns an error, the shell assumes you *literally* meant the 
file named /some/path/* and what is actually executed is "/usr/bin/sudo 
ls /some/path/*" (one program, two arguments). Then sudo elevates your 
priviledges and executes "ls /some/path/*" (one program, one argument, 
sudo does not expand wildcards on its own). The ls, now working as 
root's process, tries to open file "/some/path/*", but because this file 
doesn't exists, you get an error "no such file".

[1] - side note: there is a limit on how many arguments a program can 
take. If you run ls * in a directory with too many files you get an 
error exactly because bash expanded the wildcard to too many separate 
arguments

[2] - I *think* csh behaves differently here

-- 
Chemical engineers do it in packed beds.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.mac.system

csiph-web