I found this snippet on the web

#!/bin/bash

for a in ./*.flac; do
< /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
done

I wanted to do more like

for a in `ls ./*.flac`; do
ffmeg - "$a" "$a".mp3
done

but it broke with each space for song names
"I Had A Dream"

I
Had
A Dream

which is not what I wanted. Can I get around this?

I also do not understand this

"${a[@]/%flac/mp3}"

On Sun, 20 Jun 2021 01:21:38 -0400, Popping Mad wrote:
> but it broke with each space for song names
> "I Had A Dream"

put it within "" or ''

or replace " " by "\ "

On 20.06.2021 07:21, Popping Mad wrote:
> I found this snippet on the web
>
> #!/bin/bash
>
> for a in ./*.flac; do
> < /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
> done
>
>
> I wanted to do more like

Amazing!

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!

So the first part of the answer is; use (as in the original
code)

for a in ./*.flac; do

>
> for a in `ls ./*.flac`; do
> ffmeg - "$a" "$a".mp3
> done
>
> but it broke with each space for song names
> "I Had A Dream"
>
>
> I
> Had
> A
> Dream
>
> which is not what I wanted. Can I get around this?
>
>
> I also do not understand this
>
>
> "${a[@]/%flac/mp3}"
>

I don't know about bash (inspect the man page!) but I suppose it
is that same as in Kornshell where it is:

${parameter/%pattern/string}

Expands parameter and replaces the longest match of pattern
with the given string. [anchored at the end of the string]

where ${a[@]} is an array variable where the substitution occurs
on each element. (This is a non-standard construct and can be
replaced by a standard one (see below).)

So it replaces a flac file extension by mp3.

What I don't understand is why a[@] (an array) is used since
you iterate over the array elements "$a" .

What you probably just want is basically

for a in ./*.flac
do
ffmeg ... "$a" ... "${a%flac}.mp3"
done

(add your other ffmpeg options as needed).

Janis

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
>

On 6/20/2021 12:21 AM, Popping Mad wrote:
> I found this snippet on the web
>
> #!/bin/bash
>
> for a in ./*.flac; do
> < /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
> done
>
>
> I wanted to do more like
>
>
> for a in `ls ./*.flac`; do
> ffmeg - "$a" "$a".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.

Popping Mad <rainbow@colition.gov> writes:

> I found this snippet on the web
>
> #!/bin/bash
>
> for a in ./*.flac; do
> < /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
> done
>
>
> I wanted to do more like
>
>
> for a in `ls ./*.flac`; do
> ffmeg - "$a" "$a".mp3
> done
>
> but it broke with each space for song names
> "I Had A Dream"

The list that results from the ls command is subject to word splitting.

> Can I get around this?

That's been explained -- don't use ls! But if you have to use the
result of some command that gives the required strings line by line
(possibly containing spaces), you can use this pattern:

ls *.flac | while read a; do command_that_processes "$a"; done

> I also do not understand this
>
> "${a[@]/%flac/mp3}"

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.

--
Ben.

Popping Mad <rainbow@colition.gov>:
>I found this snippet on the web
>
>
>#!/bin/bash
>
>for a in ./*.flac; do
> < /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
>done
>
>
>I wanted to do more like
>
>
>for a in `ls ./*.flac`; do
>ffmeg - "$a" "$a".mp3
>done

Why not just do “for a in ./*.flac; do”?

>but it broke with each space for song names
>

Yes.  That is field splitting.  See
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05>
for an explanation.

for a in `ls ./*.flac`; do

will not work (because of field splitting), neither will

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

do.  Certainly, in the second form, there is no field splitting
because of the double quotes.  But because “ls” doesn't put any
unambiguous fences between one filename and the other into its
output, the shell will not be able to tell the end of one filename
and the beginning of the next.  => All output from “ls” will be
assigned as one word to the variable “a”, which is not what you
want, either.

>Can I get around this?
>

Yes.  Just let the shell rather than “ls” collect the filenames:

for a in ./*.flac
do
if ! test -e "$a" && ! test -L "$a"
then
continue
fi
ffmeg - "$a" "$a".mp3
done

On 2021-06-20, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
> Popping Mad <rainbow@colition.gov>:
>>I found this snippet on the web
>>
>>
>>#!/bin/bash
>>
>>for a in ./*.flac; do
>> < /dev/null ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"
>>done
>>
>>
>>I wanted to do more like
>>
>>
>>for a in `ls ./*.flac`; do
>>ffmeg - "$a" "$a".mp3
>>done
>
> Why not just do “for a in ./*.flac; do”?

One reason might be that it breaks on the case when there is no match,
stupidly producing the pattern syntax itself as the expansion.

Whereas $(ls pattern), though complaining with a diagnostic on stderr,
will correctly produce an empty expansion rather than pattern.

This is why ls sometimes gets used instead of just globbing even by
people who know what they are doing.

ls will receive the unexpanded non-matching pattern as an argument, and
then consume it.

On 20.06.2021 19:46, Kaz Kylheku wrote:
> On 2021-06-20, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>> Popping Mad <rainbow@colition.gov>:
>>> #!/bin/bash
>>
>> Why not just do “for a in ./*.flac; do”?
>
> One reason might be that it breaks on the case when there is no match,
> stupidly producing the pattern syntax itself as the expansion.

In bash - seen used by the OP - that can at least be addressed by

shopt -s nullglob

(It would make sense to standardize some function like that.)

Janis

Kaz Kylheku <563-365-8930@kylheku.com>:
>On 2021-06-20, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>> Popping Mad <rainbow@colition.gov>:

>>>I wanted to do more like
>>>
>>>
>>>for a in `ls ./*.flac`; do
>>>ffmeg - "$a" "$a".mp3
>>>done
>>
>> Why not just do “for a in ./*.flac; do”?
>>
>
>One reason might be that it breaks on the case when there is no
>match, stupidly producing the pattern syntax itself as the
>expansion.

Yes.  That's why I did

if ! test -e "$a" && ! test -L "$a"
then
continue
fi

in the body of the loop.

>Whereas $(ls pattern), though complaining with a diagnostic on stderr,
>will correctly produce an empty expansion rather than pattern.
>
>This is why ls sometimes gets used instead of just globbing even by
>people who know what they are doing.
>
>ls will receive the unexpanded non-matching pattern as an argument, and
>then consume it.

The tests for inode existence above will do the same.  But I agree
with Janis:  I'd like

shopt -s nullglob

or

set -o nullglob

to become part of the standard.

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

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

merlyn@stonehenge.com (Randal L. Schwartz) writes:
> 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. :)

\n (a backslash followed by n) could also be an interesting test.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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.

flatbush:[ruben]:~$ ./*
bash: ./abr2.mp4: Permission denied

Aside from that the output is lines, and you don't expect it to break up
into words suddenly.

So there is nothing to be amazed at. It is simple language syntax,
nouns and verbs, that one would expect.

Why it breaks the script is my puzzle.

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.

No idea what you are talking about

for i in ./*
do
....
done

Eg,
for i in ./*
do
echo "$i"
done

..
..
../StJohnsReservation (1).doc
..
..

>
> flatbush:[ruben]:~$ ./*
> bash: ./abr2.mp4: Permission denied

You really do not to read what people say.

>
> Aside from that the output is lines, and you don't expect it to break up
> into words suddenly.
>
> So there is nothing to be amazed at. It is simple language syntax,
> nouns and verbs, that one would expect.
>
>
> Why it breaks the script is my puzzle.

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?

> 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!

Kaz Kylheku <563-365-8930@kylheku.com> writes:
[...]
> for x in ./* ; do ...
[...]

I realize people are quoting articles from upthread, but is there any
particular reason to write
for x in ./* ; do ...
rather than
for x in * ; do ...
?

I know it matters in some contexts (for example, "echo *" if the first
file in the current directory is named "-n"), but it shouldn't matter
here as far as I can tell.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 23.06.2021 01:58, Popping Mad 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.

In which mental universe?

> A random ./* in the middle of a shell
> statement with out an instruction like ls is naked.

I think it makes no sense to discuss your mental picture of a
"naked construct or shell statement" (or whatever). It makes
more sense to understand shell syntax and semantics; that is
something you have to start.

Deviating from an existing (working) construct is the problem;
a problem that you introduced.

>
> flatbush:[ruben]:~$ ./*
> bash: ./abr2.mp4: Permission denied

So what? - The pattern expands by file globbing and gets a list
of matches. Since there is neither a shell construct (like 'for'
loop) nor a command (like 'echo') the first expanded word will
be treated as command. (If the first expanded word would be a
command, incidentally, that would even run. - Just to be sure;
I tell you that just for understanding the matter, not that you
should call the programs that way.)

Any globbing pattern will expand (if globbing is activated as it
is per default). You can put such patterns in any context where
it makes sense. (For example in a 'for'-loop, as argument to an
'echo' (or other) command, etc.)

>
> Aside from that the output is lines, and you don't expect it to break up
> into words suddenly.

Are you talking about the output of 'ls' or what? - Anyway you
don't see the output of ls if you put other constructs around
where (likely already mentioned) "word-splitting" happens.

Nothing here happens "suddenly". You transformed the code without
knowing what happens, and it just works as that specific shell
syntax is supposed to work.

>
> So there is nothing to be amazed at. It is simple language syntax,
> nouns and verbs, that one would expect.

Here are some more nouns and verbs: You fill water into a bottle,
turn the bottle horizontally, and are wondering why the water is
now leaving the bottle. - There is something like gravity! - In
shell it's syntax and operational semantics that rule how scripts
behave.

What is amazing is that you turned the bottle and expect the same
result that the water still stays within.

>
>
> Why it breaks the script is my puzzle.

Try understanding the operational semantics of "word splitting" in
the given context.

Try understanding how file globbing (expansion of file names given
shell patterns) works.

Janis

On 23.06.2021 05:38, Keith Thompson wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
> [...]
>> for x in ./* ; do ...
> [...]
>
> I realize people are quoting articles from upthread, but is there any
> particular reason to write
> for x in ./* ; do ...
> rather than
> for x in * ; do ...
> ?

In this context; not that I know of. Usually that code pattern is used
in contexts where arguments to commands may expand to some looking like
an option (e.g. having a leading '-' in their name) and may thus corrupt
the interpretation of the argument list by the command. (Some commands
have means to prevent that, '--'.) So folks may use the same construct
unnecessarily just because they are used to. (It doesn't hurt anyway.)

Janis

>
> I know it matters in some contexts (for example, "echo *" if the first
> file in the current directory is named "-n"), but it shouldn't matter
> here as far as I can tell.
>

In article <sav5mt$ql$1@news-1.m-online.net>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>On 23.06.2021 01:58, Popping Mad 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.
>
>In which mental universe?
>
>> A random ./* in the middle of a shell
>> statement with out an instruction like ls is naked.
>
>I think it makes no sense to discuss your mental picture of a
>"naked construct or shell statement" (or whatever). It makes
>more sense to understand shell syntax and semantics; that is
>something you have to start.

Maybe this is a "boss problem". Maybe his boss doesn't like the accepted
paradigm and prefers "for i in $(ls) ...". I'm guessing that boss saw his
code and told him to change it, so he came here looking for help.

Remember, bosses tend to be set in their ways. That's how they became bosses.
And, I'm actually sympathetic. I can see how the "for i in $(ls) ..."
style just "looks" more "symmetric". If you get used to most lines of code
looking like:

something $(somethingelse)

Then I can see how the other form would be jarring.

Maybe his boss is The Orange One (aka, The Former Guy). He is renowned for
insisting that reality be changed to fit his views, rather than the other
way around. Think: hurricanes in Alabama...

And, remember, as long as the boss is the one signing your paycheck, the
boss is always right.

--
When I was growing up we called them "retards", but that's not PC anymore.
Now, we just call them "Trump Voters".

The question is, of course, how much longer it will be until that term is also un-PC.

On 23.06.2021 15:03, Kenny McCormack wrote:
>
> Maybe this is a "boss problem". Maybe his boss doesn't like the accepted
> paradigm and prefers "for i in $(ls) ...". I'm guessing that boss saw his
> code and told him to change it, so he came here looking for help.

To me it sounded more like a hongyi-mindset, i.e. a way of thinking
I have difficulties to get connected to.

> Remember, bosses tend to be set in their ways. That's how they became bosses.
> And, I'm actually sympathetic. I can see how the "for i in $(ls) ..."
> style just "looks" more "symmetric".

Ah, symmetry! - So this must be the solution... (for a problem yet
to be defined)

boss=sob
for ni in rof
do echo ohce od
yes < sey | yes > sey
done # enod

It has the nice property that usually it leads to an error, but a
second call will "suddenly" (as the OP used a formulation) fix it.

In practice; after running it with an error you detect that line 1
is the erroneous one - broken symmetry! - so you install two groups
to try (in the same environment) fixes based on the broken symmetry
hypothesis; one is trying bos=sob and the other boss=ssob . Each
group then "coherently"[OP] observes a success: no error. - q.e.d.
(It obviously was the broken symmetry!)

Janis

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.

However, I think recent versions of ls show control characters with
escape sequences by default.

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

In comp.unix.shell, Barry Margolin <barmar@alum.mit.edu> wrote:
> 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. :)

I have heard the autoconf commands get rather out of sorts doing builds
in directories like that. I haven't actually tried, have you?

> If you really want to freak them out, put \r in the filenames.
>
> However, I think recent versions of ls show control characters with
> escape sequences by default.

Yeah, but to me "space" isn't a control character, so I find it somewhat
annoying.

Expert level is entire terminal control sequences in filenames. Not sure
if the Tektronix sequences are short enough to be practical. Here's a
demo of abusing them with `cat`ed files:

https://lock.cmpxchg8b.com/tektronix.html

Elijah
------
found the demo quite funny

On 26.06.21 21:21, 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.

<code>
#! /usr/bin/perl

use warnings;
use strict;

my $path = join("\xe2\x88\x95", '', @ARGV);
if (open(my $dst, '>', $path)) {
binmode $dst;
print $dst $path, "\n";
close $dst;
} </code>

Try "script a b c" ;-)

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"

On 6/22/21 8:44 PM, William Unruh wrote:
> You really do not to read what people say.

you really didn't make any contribution to this discussion