On 6/22/21 8:46 PM, Kaz Kylheku wrote:
> On 2021-06-22, Popping Mad <rainbow@colition.gov> wrote:
>> On 6/20/21 6:04 AM, Janis Papanagnou wrote:
>>> It's beyond me why folks dismiss a correct and efficient
>>> construct (a simple for-loop file pattern) and want to
>>> replace it by wrong and inefficient constructs (subshell
>>> and ls) - ...and then wonder why the code breaks!
>>
>>
>> well, because it is incoherent. A random ./* in the middle of a shell
>> statement with out an instruction like ls is naked.
>
> There is a bleeping instruction: "for x in"!
>
> for x in ./* ; do ...
>
>
>> flatbush:[ruben]:~$ ./*
>> bash: ./abr2.mp4: Permission denied
>
> Strawman nonsense. Nick checks out?

On 6/22/21 8:46 PM, Kaz Kylheku wrote:
> Nouns ... verbs

subject and ojects

../* is not a command in bash in of itself.

for x in expects a list

this is not a list ./*

`ls ./*`

does produce a list. That is how I think about it. Obviously, I am wrong.

>
>> So there is nothing to be amazed at. It is simple language syntax,
>> nouns and verbs, that one would expect.
>
> Yeah, simple language.
>
> Nouns ... verbs ... nested backticks with an embedded useless ls ...
>
> You know, natural!
>

On 6/20/21 10:05 AM, Ed Morton wrote:
>> ".mp3
>> done
>>
>> but it broke with each space for song names
>
> Some shell programming fundamentals:
>
> https://mywiki.wooledge.org/DontReadLinesWithFor
> https://mywiki.wooledge.org/BashFAQ/001
> https://mywiki.wooledge.org/ParsingLs
>
>     Ed.

thanks

On 6/20/21 10:28 AM, Ben Bacarisse wrote:
> The list that results from the ls command is subject to word splitting.

and not from ./* ?

On 6/20/21 10:28 AM, Ben Bacarisse wrote:
> For some reason the author is treating a as an array. This is harmless,
> but unless I'm missing something, it's also pointless. You could write
>
> "${a/%flac/mp3}"
>
> instead. The ${var/s1/s2} syntax gives the value of $var but with the
> first occurrence of s1 replaced by s2. In the % form (${var/%s1/s2}) s1
> must match as the end of $var

Excellent - thanks

On 6/20/21 1:13 PM, Helmut Waitzmann wrote:
>   for a in `ls ./*.flac`; do
>
> will not work (because of field splitting), neither will
>
>   for a in "`ls ./*.flac`"; do

but why is the default field split a space for the ls execution and not
for ./* ?

On 6/20/21 1:13 PM, Helmut Waitzmann wrote:
>   for a in `ls ./*.flac`; do
>
> will not work (because of field splitting), neither will
>
>   for a in "`ls ./*.flac`"; do

but why is the default field split a space for the ls execution and not
for ./* ?

On 2021-06-29, Popping Mad <rainbow@colition.gov> wrote:
>
>
> On 6/22/21 8:46 PM, Kaz Kylheku wrote:
>> Nouns ... verbs
>
> subject and ojects
>
> ./* is not a command in bash in of itself.
>
> for x in expects a list
>
> this is not a list ./*
>
> `ls ./*`

actually
for x in ./*
is a list. The shell expands ./* before it runs the command (for x in)
so that will produce a whole list of items -- all of the filenames that
do not start with . in the current directory.
Try
for i in ./*
do
echo $i
done

>
> does produce a list. That is how I think about it. Obviously, I am wrong.
>
>>

On 30.06.2021 01:48, Popping Mad wrote:
> On 6/20/21 7:25 AM, Janis Papanagnou wrote:
>> Oops..
>>
>> On 20.06.2021 12:04, Janis Papanagnou wrote:
>>>
>>> What you probably just want is basically
>>>
>>> for a in ./*.flac
>>> do
>>> ffmeg ... "$a" ... "${a%flac}.mp3"
>>
>> ffmeg ... "$a" ... "${a%.flac}.mp3"
>>
>>> done
>>>
>>> (add your other ffmpeg options as needed).
>>>
>>> Janis
>>>
>>
>
>
> what is this syntax
> "${a%.flac}.mp3"

The shell standard expression

${var%suffix}

is removing the 'suffix' (if present) from the variable 'var'.
The ".mp3" part is just a new suffix that gets concatenated.

Janis

On 30.06.2021 02:01, Popping Mad wrote:
> On 6/20/21 10:28 AM, Ben Bacarisse wrote:
>> For some reason the author is treating a as an array. This is harmless,
>> but unless I'm missing something, it's also pointless. You could write
>>
>> "${a/%flac/mp3}"
>>
>> instead. The ${var/s1/s2} syntax gives the value of $var but with the
>> first occurrence of s1 replaced by s2. In the % form (${var/%s1/s2}) s1
>> must match as the end of $var
>
>
> Excellent - thanks

Note that this is a non-standard construct (that you find in some
prominent shells, though), and note that it is unnecessary since
you can do that with a standard shell construct as well

"${a%flac}mp3"

Janis

On 30.06.2021 01:59, Popping Mad wrote:
> On 6/20/21 10:28 AM, Ben Bacarisse wrote:
>> The list that results from the ls command is subject to word splitting.
>
> and not from ./* ?

It's a question in which order the shell does the command processing
steps. Word splitting is done before pathname expansion from globbing.
(Google for or inspect the shell documentation for Command Processing.)

Janis

On 30.06.2021 02:03, Popping Mad wrote:
> On 6/20/21 1:13 PM, Helmut Waitzmann wrote:
>> for a in `ls ./*.flac`; do
>>
>> will not work (because of field splitting), neither will
>>
>> for a in "`ls ./*.flac`"; do
>
>
> but why is the default field split a space for the ls execution and not
> for ./* ?

Google for or inspect the shell documentation for Command Processing.

Janis

On 30.06.2021 01:55, Popping Mad wrote:
> subject and ojects
>
> ./* is not a command in bash in of itself.
>
> for x in expects a list
>
> this is not a list ./*

No, this is not a list. It is a pattern that expands to a list of
matching filenames. The filenames may contain spaces, since field
splitting has already be performed at that stage and the semantic
entity of a filename is still preserved here.

>
> `ls ./*`
>
> does produce a list.

.* produces a list of matching files

ls ./* calls ls with the list of files and (depending on the options)
does several things with each of the arguments in the list
(and ls still sees the correct filename entities with spaces)

`ls ./*` calls a subshell and within it executes the given command
after having expanded the matching files for that command;
ls will see the filename entities because at the instance
of time when the filename expansion took place the field
splitting has already be done. The result of the command
execution from the subshell will then be expanded in a
sequence of words (not a sequence of filenames) separated
by a blank (per default), since the field splitting will
then happen (in the outer shell context; you should be
aware that we have two levels of shell instances with the
`...` construct here - to make that fact apparent is one
of many reasons to use $(...) instead as the modern/better
alternative, but which of course behaves equivalently with
respect to field splitting).

> That is how I think about it. Obviously, I am wrong.

Obviously.

Janis

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

> On 30.06.2021 02:01, Popping Mad wrote:
>> On 6/20/21 10:28 AM, Ben Bacarisse wrote:
>>> For some reason the author is treating a as an array. This is harmless,
>>> but unless I'm missing something, it's also pointless. You could write
>>>
>>> "${a/%flac/mp3}"
>>>
>>> instead. The ${var/s1/s2} syntax gives the value of $var but with the
>>> first occurrence of s1 replaced by s2. In the % form (${var/%s1/s2}) s1
>>> must match as the end of $var
>>
>>
>> Excellent - thanks
>
> Note that this is a non-standard construct (that you find in some
> prominent shells, though), and note that it is unnecessary since
> you can do that with a standard shell construct as well
>
> "${a%flac}mp3"

I held off suggesting that because it does not do exactly the same
thing. Won't matter in this case (the OP loops over ".flac" files) but
then they also said they were using bash.

--
Ben.

On 30.06.2021 12:52, Ben Bacarisse wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
>
>> On 30.06.2021 02:01, Popping Mad wrote:
>>> On 6/20/21 10:28 AM, Ben Bacarisse wrote:
>>>> For some reason the author is treating a as an array. This is harmless,
>>>> but unless I'm missing something, it's also pointless. You could write
>>>>
>>>> "${a/%flac/mp3}"
>>>>
>>>> instead. The ${var/s1/s2} syntax gives the value of $var but with the
>>>> first occurrence of s1 replaced by s2. In the % form (${var/%s1/s2}) s1
>>>> must match as the end of $var
>>>
>>>
>>> Excellent - thanks
>>
>> Note that this is a non-standard construct (that you find in some
>> prominent shells, though), and note that it is unnecessary since
>> you can do that with a standard shell construct as well
>>
>> "${a%flac}mp3"
>
> I held off suggesting that because it does not do exactly the same
> thing. Won't matter in this case (the OP loops over ".flac" files) but
> then they also said they were using bash.

I haven't meant to say that these two code patterns would do the same.
(Actually, I haven't even pondered about that question; mainly because
the non-standard code pattern wasn't really necessary here.)

Why use "${a/%flac/mp3}" in the first place?

Generally, if I can use a standard construct for a given case without
any negative effects (that some non-standard construct might address),
I go for the standard. (YMMV.) And that's independent of the shell I
use. (I use ksh, a shell much more powerful than standard sh or bash;
nonetheless I restrict myself as much as possible - but it should not
hurt! :-) - to feature subsets of the prominent shells (incl. bash)
or even standard sh; as said, if it doesn't hurt.)

For example I regularly use the non-standard ${var/s1/s2} because all
the standard counterparts are inefficient or bulky. But here the good
old ${a%s} is fine and there's no need (for me) to introduce something
else that is more "complex" and non-standard.

Janis

In article <sbhe9l$rsj$1@news-1.m-online.net>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
....
>Note that this is a non-standard construct (that you find in some
>prominent shells, though), and note that it is unnecessary since
>you can do that with a standard shell construct as well
>
> "${a%flac}mp3"

Yes, but the replacement syntax is more appealing to the eye - and makes
more intuitive sense.

I.e., my mindset is "replace this with that", not "remove this" and then
"append that". Yes, I know they are equivalent, but I think it is worth
using something "non-standard" to get some mental clarity.

Going "non-standard" don't upset me much...

--
Trump has normalized hate.

The media has normalized Trump.

In article <sbhdrn$rrr$1@news-1.m-online.net>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
....
>The shell standard expression
>
> ${var%suffix}
>
>is removing the 'suffix' (if present) from the variable 'var'.
>The ".mp3" part is just a new suffix that gets concatenated.

Actually, it does not remove it from the variable 'var'; the original
contents is kept intact. All it does is return a string contructed from
the contents of the variable, with the 'suffic' removed.

--
Christianity is not a religion.

- Rick C Hodgin -

On 30.06.2021 14:55, Kenny McCormack wrote:
> In article <sbhdrn$rrr$1@news-1.m-online.net>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> ...
>> The shell standard expression
>>
>> ${var%suffix}
>>
>> is removing the 'suffix' (if present) from the variable 'var'.
>> The ".mp3" part is just a new suffix that gets concatenated.
>
> Actually, it does not remove it from the variable 'var'; the original
> contents is kept intact. All it does is return a string contructed from
> the contents of the variable, with the 'suffic' removed.

Right. Thanks for fixing my formally imperfect explanation.

These substitutions (at least the standard ones) all work the way
you describe, with the exception of ${var=val} and ${var:=val}
that do an assignment to the variable.

Janis

On 30.06.2021 14:51, Kenny McCormack wrote:
> In article <sbhe9l$rsj$1@news-1.m-online.net>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> ...
>> Note that this is a non-standard construct (that you find in some
>> prominent shells, though), and note that it is unnecessary since
>> you can do that with a standard shell construct as well
>>
>> "${a%flac}mp3"
>
> Yes, but the replacement syntax is more appealing to the eye - and makes
> more intuitive sense.

I also think that intuitive clarity is a factor to consider. The
concrete preferred code pattern certainly depends on the individual
(and probably also on the code context).

> I.e., my mindset is "replace this with that", not "remove this" and then
> "append that". Yes, I know they are equivalent, but I think it is worth
> using something "non-standard" to get some mental clarity.
>
> Going "non-standard" don't upset me much...

Janis

Popping Mad <rainbow@colition.gov>:
>On 6/20/21 1:13 PM, Helmut Waitzmann wrote:

>>   for a in `ls ./*.flac`; do
>>
>> will not work (because of field splitting), neither will
>>
>>
>>   for a in "`ls ./*.flac`"; do
>
>
>but why is the default field split a space for the ls execution and
>not for ./* ?

Please look up
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html>,
which is the detailed table of contents of the ‘Shell & Utilities’
document of the POSIX standard.

In this table of contents, look for the ‘Shell Command Language’
chapter, which describes the behavior of the shell.  (The following
URLs denote parts of that chapter.)

In the commandline

for a in ./*.flac ; do echo "$a" ; done

the shell will recognize the unquoted string ‘./*.flac’ as a
pathname pattern (because of the ‘*’, see
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
and expand it as described in
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_06>,
thus getting a list of pathnames.

The shell will assign the variable ‘a’ each of the pathnames, one
at a time, and invoke the ‘echo’ command with that pathname as a
parameter.

On the other hand, in the commandline

for a in `ls ./*.flac` ; do echo "$a" ; done

the shell will recognize the ‘`…`’ as command substitution
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03>): 
It will invoke a subshell environment, which will parse the

ls ./*.flac

commandline.  Like above, the subshell will recognize the unquoted
string ‘./*.flac’ as a pathname pattern and expand it, thus invoking
the ‘ls’ utility on a list of pathnames.

The ‘ls’ utility will lookup each of the given pathnames and output
some information (for example the name) of each pathname, separated
by a newline.

For example, if in the current directory there are two regular files
with filenames

‘a file.flac’

(containing a space character) and

‘a
twoliner.flac’

(containing a newline character) respectively.  Then the output of

ls *.flac

will be the following three lines:

../a file.flac
../a
twoliner.flac

As you can already see, there is no way for you to tell from the
output of the ‘ls’ utility, whether ‘ls’ has seen one (strange but
valid) filename:

‘./a file.flac
../a
twoliner.flac’

or two filenames:

‘./a file.flac’

and

‘./a
twoliner.flac’

or even three filenames:

‘./a file.flac’,

‘./a’,

and

‘twoliner.flac’.

And of course the shell won't be able to distinguish those three
cases, as well:

If you use the commandline

for a in "`ls …`" ; do

(note the double quotes) then the shell will not do any field
splitting on the output of the ‘ls’ command, i. e. it will interpret
the output of the ‘ls’ command as the threeliner pathname

‘./a file.flac
../a
twoliner.flac’.

If on the other hand you use the commandline

for a in `ls …` ; do

then the shell will do field splitting on the output of the ‘ls’
command, i. e. it will split that output at each white space
character (blanks, tabs and newlines; more precisely: according to
the characters that are part of the value of the ‘IFS’ shell
variable, which by default are blanks, tabs, and newlines; see
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05>). 

Thus it will assign the variable ‘a’ the values ‘./a’,
‘file.flac’, ‘./a’, and ‘twoliner.flac’, one at a time.

=> Neither the ‘"`ls`"’ nor the ‘`ls`’ variant will preserve the
original filenames.  Both of them will just not work.

To come back to your question:

>but why is the default field split a space for the ls execution and
>not for ./* ?

If you use the commandline

for a in ./*.flac ; do echo "$a" ; done

then the shell will gather the matching pathnames and assign them to
the variable ‘a’ one at a time, invoking the ‘echo’ command for each
of the pathnames.  The pathnames are neither glued together (with
newlines in between like ‘ls’ does), nor are they undergone field
splitting.

=> The pathnames are left intact.

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

> On 30.06.2021 12:52, Ben Bacarisse wrote:
>> Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
>>
>>> On 30.06.2021 02:01, Popping Mad wrote:
>>>> On 6/20/21 10:28 AM, Ben Bacarisse wrote:
>>>>> For some reason the author is treating a as an array. This is harmless,
>>>>> but unless I'm missing something, it's also pointless. You could write
>>>>>
>>>>> "${a/%flac/mp3}"
>>>>>
>>>>> instead. The ${var/s1/s2} syntax gives the value of $var but with the
>>>>> first occurrence of s1 replaced by s2. In the % form (${var/%s1/s2}) s1
>>>>> must match as the end of $var
>>>>
>>>>
>>>> Excellent - thanks
>>>
>>> Note that this is a non-standard construct (that you find in some
>>> prominent shells, though), and note that it is unnecessary since
>>> you can do that with a standard shell construct as well
>>>
>>> "${a%flac}mp3"
>>
>> I held off suggesting that because it does not do exactly the same
>> thing. Won't matter in this case (the OP loops over ".flac" files) but
>> then they also said they were using bash.
>
> I haven't meant to say that these two code patterns would do the same.
> (Actually, I haven't even pondered about that question; mainly because
> the non-standard code pattern wasn't really necessary here.)
>
> Why use "${a/%flac/mp3}" in the first place?

We may never know. The OP posted code from someone else and asked about
what it meant. I was explaining it. I stopped short of correcting it.

--
Ben.

On 6/30/21 1:26 AM, William Unruh wrote:
> actually
> for x in ./*
> is a list. The shell expands ./* before it runs the command (for x in)
> so that will produce a whole list of items -- all of the filenames that
> do not start with . in the current directory.
> Try
> for i in ./*
> do
> echo $i
> done

I thought that only happened when their is a command to take the glob as
an argument. I didn't know that the shell takes that as a command.

On 6/30/21 6:16 AM, Janis Papanagnou wrote:
> On 30.06.2021 01:55, Popping Mad wrote:
>> subject and ojects
>>
>> ./* is not a command in bash in of itself.
>>
>> for x in expects a list
>>
>> this is not a list ./*
>
> No, this is not a list. It is a pattern that expands to a list of
> matching filenames. The filenames may contain spaces, since field
> splitting has already be performed at that stage and the semantic
> entity of a filename is still preserved here.
>
>>
>> `ls ./*`
>>
>> does produce a list.
>
> .* produces a list of matching files
>
> ls ./* calls ls with the list of files and (depending on the options)
> does several things with each of the arguments in the list
> (and ls still sees the correct filename entities with spaces)
>
> `ls ./*` calls a subshell and within it executes the given command
> after having expanded the matching files for that command;
> ls will see the filename entities because at the instance
> of time when the filename expansion took place the field
> splitting has already be done. The result of the command
> execution from the subshell will then be expanded in a
> sequence of words (not a sequence of filenames) separated
> by a blank (per default), since the field splitting will
> then happen (in the outer shell context; you should be
> aware that we have two levels of shell instances with the
> `...` construct here - to make that fact apparent is one
> of many reasons to use $(...) instead as the modern/better
> alternative, but which of course behaves equivalently with
> respect to field splitting).
>
>> That is how I think about it. Obviously, I am wrong.
>
> Obviously.
>
> Janis
>

Thanks!

On 16.07.2021 03:23, Popping Mad wrote:
> On 6/30/21 1:26 AM, William Unruh wrote:
>> actually
>> for x in ./*
>> is a list. The shell expands ./* before it runs the command (for x in)
>> so that will produce a whole list of items -- all of the filenames that
>> do not start with . in the current directory.
>> Try
>> for i in ./*
>> do
>> echo $i
>> done
>
> I thought that only happened when their is a command to take the glob as
> an argument. I didn't know that the shell takes that as a command.

Could it be that you are coming from the Windows/DOS world?
I am asking because in DOS (AFAIR) it had been the case that the
command line was (WRT the "wildcard" characters * and ? ) literally
passed to the command, and it was every _command's_ responsibility
(as opposed to the shell or "command interpreter") to expand the
"wildcard" characters to create file lists. In Unix the shell does
these (and other) expansions. - Could that have been the source of
your confusion?

Janis

with <sct9ca$e2k$1@news-1.m-online.net> Janis Papanagnou wrote:
> On 16.07.2021 03:23, Popping Mad wrote:
>> On 6/30/21 1:26 AM, William Unruh wrote:

>>> actually for x in ./* is a list. The shell expands ./* before it
>>> runs the command (for x in) so that will produce a whole list of
>>> items -- all of the filenames that do not start with . in the
>>> current directory.
*SKIP*
>> I thought that only happened when their is a command to take the glob
>> as an argument. I didn't know that the shell takes that as a
>> command.
> Could it be that you are coming from the Windows/DOS world? I am
> asking because in DOS (AFAIR) it had been the case that the command
> line was (WRT the "wildcard" characters * and ? ) literally passed to
> the command, and it was every _command's_ responsibility (as opposed
> to the shell or "command interpreter") to expand the "wildcard"
> characters to create file lists. In Unix the shell does these (and
> other) expansions. - Could that have been the source of your
> confusion?

s/had been/is/ s/was/is/g

Also, handling of command line by GUI isn't any better and there's no
escaping (only double-quotes that act like as single-quotes in the
shell). As a result charging multiple files with spaces in filenames
will ensue extreme frustration for non-mouse-massaging types.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Barry Margolin wrote:

> In article <86pmwguqr4.fsf@red.stonehenge.com>, merlyn@stonehenge.com
> (Randal L. Schwartz) wrote:
>
>> You think spaces in filenames are weird? I often made a habit of making
>> a directory named \n (well, a literal newline) to test my shell scripts.
>> I figured if they could deal with a newline, they could probably deal
>> with most other things. Also to freak out people peeking at my $HOME. :)
>
> If you really want to freak them out, put \r in the filenames.

macOS lets users assign custom icons to files and folders. When you do it
for a folder, the system stores the icon in the folder in a file named
"Icon\r", with a 0D byte at the end. These files are hidden in most
contexts, but occasionally an application will include one in a file
listing, and then you usually see the bottom half of the word "Icon" with a
weird space under it.

(It looks like you're posting from a Mac, so maybe you were alluding to
this.)

The built-in (BSD) ls renders these files as Icon? in file listings, which
is... not super helpful. GNU ls and exa both display the name more
explicitly, as 'Icon'$'\r' or Icon\r (with the \r in red), respectively.

Benjamin