In article <slrntarjm8.phb.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:

with <t8je2e$unq$1@dont-email.me> Janis Papanagnou wrote:

On 18.06.2022 02:16, Brian Patrie wrote:

*SKIP*

So what to do then? - Something like this...?
zsh -c 'set -o nullglob ; echo W[0-5][0-9](N/^F)' | xargs -r rmdir

You can do better:

zsh -Gc 'echo W[0-5][0-9](/^F)' | xargs -r rmdir

If you're willing to go that far down the rabbit-hole, wouldn't it be
easier to just write a cuatom C program to do what you want?

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FiftyPercent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t8l3s0$1o173$1@news.xmission.com> Kenny McCormack wrote:

In article <slrntarjm8.phb.whynot@orphan.zombinet>, Eric Pozharski <whynot@pozharski.name> wrote:

with <t8je2e$unq$1@dont-email.me> Janis Papanagnou wrote:

On 18.06.2022 02:16, Brian Patrie wrote:

*SKIP*

If you're willing to go that far down the rabbit-hole, wouldn't it be
easier to just write a cuatom C program to do what you want?

That's the point! Finally, another concerned voice.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.06.2022 20:00, Kenny McCormack wrote:

In article <slrntarjm8.phb.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:

with <t8je2e$unq$1@dont-email.me> Janis Papanagnou wrote:

On 18.06.2022 02:16, Brian Patrie wrote:

*SKIP*

So what to do then? - Something like this...?
zsh -c 'set -o nullglob ; echo W[0-5][0-9](N/^F)' | xargs -r rmdir

You can do better:

zsh -Gc 'echo W[0-5][0-9](/^F)' | xargs -r rmdir

If you're willing to go that far down the rabbit-hole, wouldn't it be
easier to just write a cuatom C program to do what you want?

I don't think the presented shell solutions would be that complex or
unhandy that writing a C-program, with a lot language overhead and a
compiler, and libraries necessary, and doing extra processing steps
would be the preferred way.

As I see it we have two options; use a variant of rmdir that already
supports the feature, or use the Unix tool-box to emulate it. In the
latter case there was the question whether modern globbing might
support that, and it seems zsh has a simple syntax for that. And the
xargs will do two jobs, address the exec-buffer issue and don't call
the program if no arguments are there (to prevent an error message).

One thing that is still disturbing me is how pathological filenames
will be handles by above code. Maybe we need something like

zsh -Gc 'printf "%s\0" W[0-5][0-9](/^F)' | xargs -0 -r rmdir

To compare with the other options

rmdir --ignore-fail-on-non-empty W[0-5][0-9]

find -maxdepth 1 -type d -name "W[0-5][0-9]" -empty -delete

and even the option '--ignore-fail-on-non-empty' doesn't look that
long any more.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t8o5mn$bam$1@dont-email.me> Janis Papanagnou wrote:

On 18.06.2022 20:00, Kenny McCormack wrote:

In article <slrntarjm8.phb.whynot@orphan.zombinet>, Eric Pozharski
<whynot@pozharski.name> wrote:

with <t8je2e$unq$1@dont-email.me> Janis Papanagnou wrote:

On 18.06.2022 02:16, Brian Patrie wrote:

*SKIP*

As I see it we have two options; use a variant of rmdir that already
supports the feature, or use the Unix tool-box to emulate it. In the
latter case there was the question whether modern globbing might
support that, and it seems zsh has a simple syntax for that. And the
xargs will do two jobs, address the exec-buffer issue and don't call
the program if no arguments are there (to prevent an error message).

Also, there is an option of *ignoring* "Directory not empty" message.
This discussion makes sense *if* (and only if) 'rmdir' would behave like
"rm -rf". But (in contrary with some other unspecified toy operating
systems) it doesn't.

One thing that is still disturbing me is how pathological filenames
will be handles by above code. Maybe we need something like

zsh -Gc 'printf "%s\0" W[0-5][0-9](/^F)' | xargs -0 -r rmdir

You can do better:

zsh -Gc 'print -N W[0-5][0-9](/^F)' | xargs -0r rmdir

To compare with the other options

rmdir --ignore-fail-on-non-empty W[0-5][0-9]

find -maxdepth 1 -type d -name "W[0-5][0-9]" -empty -delete

and even the option '--ignore-fail-on-non-empty' doesn't look that
long any more.

Also, docu of 'xargs' is misleading:

% print -N | xargs -0r md5sum
md5sum: '': No such file or directory

Turns out, separators (and even sole terminator) makes input non-empty.

May I intrigue you with simulating 'find' (zsh here, I'm pretty certain
doesn't work in bash):

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir $slvr

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.06.2022 06:52, Janis Papanagnou wrote:

On 20.06.2022 16:03, Eric Pozharski wrote:

May I intrigue you with simulating 'find' (zsh here, I'm pretty certain
doesn't work in bash):

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir $slvr

The zsh globbing would not work in ksh and probably not in bash.

But wouldn't that code (also in zsh) better be formulated as

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir "${slvr[@]}"

since "${slvr[@]}" is the standard to access array elements, and
filenames with spaces (etc.) would have issues (in ksh and bash).

Missed another thing; I'd probably write for the test one of

(( ${#slvr} )) or [[ ${#slvr} != 0 ]]

Or is $slvr safe in that respect in zsh?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.06.2022 16:03, Eric Pozharski wrote:

May I intrigue you with simulating 'find' (zsh here, I'm pretty certain doesn't work in bash):

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir $slvr

The zsh globbing would not work in ksh and probably not in bash.

But wouldn't that code (also in zsh) better be formulated as

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir "${slvr[@]}"

since "${slvr[@]}" is the standard to access array elements, and
filenames with spaces (etc.) would have issues (in ksh and bash).
Or is $slvr safe in that respect in zsh?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t8rk4k$1or$1@dont-email.me> Janis Papanagnou wrote:

On 21.06.2022 06:52, Janis Papanagnou wrote:

On 20.06.2022 16:03, Eric Pozharski wrote:

May I intrigue you with simulating 'find' (zsh here, I'm pretty
certain doesn't work in bash):

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir $slvr

The zsh globbing would not work in ksh and probably not in bash.

I declare zero knowledge of ksh. Right now, I'm restricted to bash in unspecified project, bash is so counter-intuitive, it's mind bogling
(probably, will take couple of days of slasheming to get sanity back).

But wouldn't that code (also in zsh) better be formulated as

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir "${slvr[@]}"

since "${slvr[@]}" is the standard to access array elements, and
filenames with spaces (etc.) would have issues (in ksh and bash).

True, (abstract) you can write bash in zsh. What's (personal) your
point?

Missed another thing; I'd probably write for the test one of

(( ${#slvr} )) or [[ ${#slvr} != 0 ]]

Or is $slvr safe in that respect in zsh?

No. Up to this very moment, I hadn't realized that Perl-False and
Shell-True are reversed. Now I know better. Thus should be:

[[ ${#slvr} ]] || rmdir $slvr

Maybe. I would say (given a parameter is *array*), how bash expands array-parameters is counter intuitive. It's not /wrong/ (bash
definetely has it's reasons), it's just so happens that way of zsh makes
more sense (for me).

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22.06.2022 14:50, Eric Pozharski wrote:

with <t8rk4k$1or$1@dont-email.me> Janis Papanagnou wrote:

But wouldn't that code (also in zsh) better be formulated as

slvr=( W[0-5][0-9](N/^F) )
[[ ${#slvr} ]] && rmdir "${slvr[@]}"

since "${slvr[@]}" is the standard to access array elements, and
filenames with spaces (etc.) would have issues (in ksh and bash).

True, (abstract) you can write bash in zsh. What's (personal) your
point?

Oh, it's just that [in ksh, bash] the $slvr in rmdir $slvr
expands to a string of elements separated also by e.g. whitespace.
That's strictly speaking not relevant in a specific case where
names like W[0-5][0-9] are expanded. But in general [in ksh, bash,
and I'd suppose also in zsh] if populating an array slvr=( ... )
to keep the argument structure intact we'd better use "${slvr[@]}"
to preserve the argument structure of the array elements and not
get undesired word splitting. Another point is that [in ksh, bash]
$slvr would not expand the whole array but only the first element.

$ a=( "A B" "C D" )
$ printf "'%s'\n" $a
'A'
'B'
$ printf "'%s'\n" "$a"
'A B'
$ printf "'%s'\n" "${a[@]}"
'A B'
'C D'

That was my point. (And a question whether zsh behaves differently
if compared to ksh, bash; as it seems to do as I've just tried.)
So for folks who are not residing solely in zsh it might be better
to use the more portable syntax that zsh also supports. For zsh-only
users my point is probably irrelevant.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t90c2e$cqs$1@dont-email.me> Janis Papanagnou wrote:

On 22.06.2022 14:50, Eric Pozharski wrote:

with <t8rk4k$1or$1@dont-email.me> Janis Papanagnou wrote:

*SKIP*

since "${slvr[@]}" is the standard to access array elements, and
filenames with spaces (etc.) would have issues (in ksh and bash).

True, (abstract) you can write bash in zsh. What's (personal) your
point?

Oh, it's just that [in ksh, bash] the $slvr in rmdir $slvr expands
to a string of elements separated also by e.g. whitespace. That's
strictly speaking not relevant in a specific case where names like W[0-5][0-9] are expanded. But in general [in ksh, bash, and I'd
suppose also in zsh] if populating an array slvr=( ... ) to keep the argument structure intact we'd better use "${slvr[@]}" to preserve the argument structure of the array elements and not get undesired word splitting. Another point is that [in ksh, bash] $slvr would not
expand the whole array but only the first element.

Well, instead walls of text I would like to see references to
specifications (or something) that clearly sets order of expansions of
bash as _standard_. Otherwise, it's just a choice that has been made
decades ago and now it's kept because backward compatibility.

$ a=( "A B" "C D" )
$ printf "'%s'\n" $a
'A'
'B'
$ printf "'%s'\n" "$a"
'A B'
$ printf "'%s'\n" "${a[@]}"
'A B'
'C D'

You point to "structure". But true difference is:

$ foo=( aa bb cc )
$ echo $foo
aa

Now, what 'rmdir' will see exactly?

That was my point. (And a question whether zsh behaves differently if compared to ksh, bash; as it seems to do as I've just tried.) So for
folks who are not residing solely in zsh it might be better to use the
more portable syntax that zsh also supports. For zsh-only users my
point is probably irrelevant.

Good. Now you (and hopefully others) realize there is world without
bash. My job here is done. Farewell... (and I'm doing that thing)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23.06.2022 11:28, Eric Pozharski wrote:

*SKIP*

"${slvr[@]}"

Well, instead walls of text I would like to see references to
specifications (or something) that clearly sets order of expansions of
bash as _standard_.

It's no "standard" in the sense of POSIX (if you meant that).
Last time I looked there's still no arrays supported by POSIX
but the positional parameters.

Otherwise, it's just a choice that has been made
decades ago and now it's kept because backward compatibility.

It's a feature (with a specific syntax) that had indeed been
introduced decades ago. That syntax for arrays, initialization
a=( ... ) and referencing the data in a structured way "${a[@]}",
has been adopted by a couple shells, and zsh seems to support
that as well. So it became a quasi-standard if you want to use
arrays (beyond the positional parameters) in those shells that
support them.

But zsh has made a couple other features and expansion decisions
that are not only non-standard but also unique to zsh. (I'm fine
with that.)

Good. Now you (and hopefully others) realize there is world without
bash. My job here is done. Farewell... (and I'm doing that thing)

Not sure what job you've actually done, but have a nice farewell.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)