glob executable vs. non executable

glob executable vs. non executable

[Ray Andrews]

I'm trying to break all 'real' files -- ignoring those weird 'special' 
files that linux makes -- into two groups: executables, which I take to 
be x-scripts, binaries and symlinks, vs. everything else, basically 
unx-scripts and plain text files.

$  eval "all_unx=( (#i)$1(N.^*) )"
... that seems to work for the later, the dot excludes symlinks but 
includes executables so: '^*' excludes those.  But what's the converse?  
I'm wanting:

$   eval "all_x=( (#i)$1(N*@) )"

... but it's a bad pattern. I can append two searches, one for '*' the 
other for '@' but I'm betting there's a clean way of doing it.  
Basically real files that whence is interested in vs. real files she is 
not interested in.  Given that these glob qualifiers have a quite 
astonishing power, it seems puzzling that ... well, I shouldn't presume 
it isn't already there, but in my mind:

$   eval "all_matches=( (#i)$1(NX )"

... anything whence finds, anything executable that is a file. Oh, and 
while I'm imagining new glob qualifiers, how about 'T': any text file, 
(un)executable script or just a cookie recipe but made of readable text.

Re: glob executable vs. non executable

[Lawrence Velázquez]

On Thu, Oct 27, 2022, at 11:41 AM, Ray Andrews wrote:
> I'm trying to break all 'real' files -- ignoring those weird 'special' 
> files that linux makes -- into two groups: executables, which I take to 
> be x-scripts, binaries and symlinks

Symbolic links are generally not considered to be executable files.
They may appear to have executable permissions, but those are usually
ignored.  What matters are the permissions of the targets.


> vs. everything else, basically 
> unx-scripts and plain text files.

What about binary files that you cannot execute, like libraries,
images, audio files, tarballs, etc.?


> $  eval "all_unx=( (#i)$1(N.^*) )"

There's almost certainly no need to use eval for this.  If $1
contains a globbing pattern, then you can allow its value to be
used as such like so:

    all_unx=( (#i)${~1}(N.^*) )

The ${~spec} form enables GLOB_SUBST for that substitution.

https://zsh.sourceforge.io/Doc/Release/Expansion.html#index-GLOB_005fSUBST_002c-toggle


> ... that seems to work for the later, the dot excludes symlinks but 
> includes executables so: '^*' excludes those.  But what's the converse?  
> I'm wanting:
>
> $   eval "all_x=( (#i)$1(N*@) )"
>
> ... but it's a bad pattern.

It's not a bad pattern; the qualifiers are just impossible to
satisfy.  You are asking for regular executable files that are ALSO
symbolic links.


> I can append two searches, one for '*' the 
> other for '@' but I'm betting there's a clean way of doing it.

Strictly speaking, you could use a comma to separate the "*" and
"@" qualifiers; this denotes a logical disjunction.  (Juxtaposition
indicates a conjunction.)

    all_unx=( (#i)${~1}(N*,@) )

However, as I said earlier, it is not useful to consider symbolic
links "executable", so this result does not make any sense.  You
probably want to find executables and *symbolic links that point
to executables*.  This can be done with the "-" qualifier, which
causes the subsequent qualifiers to operate on symbolic links'
targets instead of on the links themselves.

    all_unx=( (#i)${~1}(N-*) )


> Basically real files that whence is interested in vs. real files she is 
> not interested in.  Given that these glob qualifiers have a quite 
> astonishing power, it seems puzzling that ... well, I shouldn't presume 
> it isn't already there, but in my mind:
>
> $   eval "all_matches=( (#i)$1(NX )"
>
> ... anything whence finds, anything executable that is a file.

Using "*" with "-" more or less covers this.


> Oh, and 
> while I'm imagining new glob qualifiers, how about 'T': any text file, 
> (un)executable script or just a cookie recipe but made of readable text.

(1)  Whether a file is a "text file" is a characteristic of its
     contents and is not appropriate for a glob qualifier.
(2)  Determining whether a file is "text" is more complicated than
     you seem to think.
(3)  If you have a utility or some code that does that to your
     satisfaction, you can use it to filter the globbing results
     via the "e" qualifier.
(4)  The "T" qualifier is already in use.


-- 
vq

Re: glob executable vs. non executable

[Ray Andrews]

On 2022-10-27 13:02, Lawrence Velázquez wrote:
> What about binary files that you cannot execute, like libraries,
> images, audio files, tarballs, etc.?
Yeah, I'm trying to cover all the possibilities.  'file' seems the most 
informative but even then there's more to say.
>      all_unx=( (#i)${~1}(N.^*) )
>
> The ${~spec} form enables GLOB_SUBST for that substitution.
Thanks, that handles it.
>
> It's not a bad pattern; the qualifiers are just impossible to
> satisfy.  You are asking for regular executable files that are ALSO
> symbolic links.
Ah! It's a test in series not in parallel.  I thought it was an OR, but 
it's an AND.
> Strictly speaking, you could use a comma to separate the "*" and
> "@" qualifiers; this denotes a logical disjunction.  (Juxtaposition
> indicates a conjunction.)
>
>      all_unx=( (#i)${~1}(N*,@) )
>
Very good.  I couldn't find any documentation on that.
> However, as I said earlier, it is not useful to consider symbolic
> links "executable"

In my head the word might be 'actionable'.  Type some word at the prompt 
and press ENTER and sometimes something happens.  What I'm trying to 
nail down is all the possibilities and what sorts of species they can 
be.  In that frame of mind, a symlink is actionable so I consider it in 
the same category as any other actionable word.

> , so this result does not make any sense.  You
> probably want to find executables and *symbolic links that point
> to executables*.  This can be done with the "-" qualifier, which
> causes the subsequent qualifiers to operate on symbolic links'
> targets instead of on the links themselves.
>
>      all_unx=( (#i)${~1}(N-*) )
>
> Using "*" with "-" more or less covers this.
Excellent, this gives me bones to chew on.  Fantastic power there if I 
can learn to use it.
>
> (1)  Whether a file is a "text file" is a characteristic of its
>       contents and is not appropriate for a glob qualifier.
Quite right.  I see it the moment you say it.  Different job.
> (2)  Determining whether a file is "text" is more complicated than
>       you seem to think.
I know it.  'file' seems to use three separate tests.  So, come to think 
of it, that's a difficult thing to ask of the shell.  One might suppose 
it's easy but it ain't.
> (3)  If you have a utility or some code that does that to your
>       satisfaction, you can use it to filter the globbing results
>       via the "e" qualifier.

> (4)  The "T" qualifier is already in use.

... just a 'for instance'.  But I see now that this is hardly the 
shell's business and even if it was, it would be one of those 
conditional expressions: > [ -T "$some_file" ] && echo "That does appear 
to be a text file but don't be too sure." <

Anyway my function works well and I rely on it, but there's always the 
next little gotcha.

Thanks Lawrence, you guys are so informative.  Learning zsh by myself 
would be next to impossible.

Re: glob executable vs. non executable

[Lawrence Velázquez]

On Thu, Oct 27, 2022, at 5:44 PM, Ray Andrews wrote:
> On 2022-10-27 13:02, Lawrence Velázquez wrote:
>> Strictly speaking, you could use a comma to separate the "*" and
>> "@" qualifiers; this denotes a logical disjunction.  (Juxtaposition
>> indicates a conjunction.)
>>
>>      all_unx=( (#i)${~1}(N*,@) )
>>
> Very good.  I couldn't find any documentation on that.

See zshexpn(1), in the paragraph immediately following the list of
glob qualifiers.  It is admittedly easy to overlook.

	More than one of these lists can be combined, separated by
	commas.  The whole list matches if at least one of the
	sublists matches (they are 'or'ed, the qualifiers in the
	sublists are 'and'ed).  Some qualifiers, however, affect
	all matches generated, independent of the sublist in which
	they are given.  These are the qualifiers 'M', 'T', 'N',
	'D', 'n', 'o', 'O' and the subscripts given in brackets
	('[...]').


>> However, as I said earlier, it is not useful to consider symbolic
>> links "executable"
>
> In my head the word might be 'actionable'.  Type some word at the prompt 
> and press ENTER and sometimes something happens.

By this definition, every possible command name is "actionable".
After all, *something* always happens.


> What I'm trying to 
> nail down is all the possibilities and what sorts of species they can 
> be.  In that frame of mind, a symlink is actionable so I consider it in 
> the same category as any other actionable word.

A symlink is not inherently more "actionable" than a regular file
that does not have executable permissions.  The target is what's
important, not the symlink.

	% ln -s /bin/date link_a
	% ln -s /etc/passwd link_b
	% ./link_a
	Thu Oct 27 18:32:17 EDT 2022
	% ./link_b
	zsh: permission denied: ./link_b

As I said in my last message, the "-" glob qualifier allows you to
include or exclude symlinks based on their targets' attributes.
There is no reason to blindly lump all symlinks together, when you
can easily pick out the ones that actually matter.


> Thanks Lawrence, you guys are so informative.  Learning zsh by myself 
> would be next to impossible.

No worries.


-- 
vq

Re: glob executable vs. non executable

[Ray Andrews]

On 2022-10-27 16:19, Lawrence Velázquez wrote:
> See zshexpn(1), in the paragraph immediately following the list of
> glob qualifiers.  It is admittedly easy to overlook.
I've always 'bounced off' the manual, I just don't have the language, 
it's written by adepts for adepts, but perhaps the time has come that 
I'm ready to try to read the thing again.
>
> By this definition, every possible command name is "actionable".
> After all, *something* always happens.
Sometimes what happens is a 'no such command' message.  But yeah, if it 
is a command and and zsh finds it, then I want to know where it comes 
from.  A builtin and a binary file are very different things.
>
> A symlink is not inherently more "actionable" than a regular file
> that does not have executable permissions.  The target is what's
> important, not the symlink.
Sure, but the symlink is the first thing acted on.   Of course one 
follows the link to wherever it leads.  I remember when Peter gave me 
'whence -S' so it was explicit.
> As I said in my last message, the "-" glob qualifier allows you to
> include or exclude symlinks based on their targets' attributes.
> There is no reason to blindly lump all symlinks together, when you
> can easily pick out the ones that actually matter.

Call it lack of confidence, but I like to see them, and then see where 
they go.  It gets better with time but when I first started with Linux 
there were times when I had no idea what was being acted on when I typed 
a command.  I'd be looking for a file when it was an alias or a 
builtin.  For a long time when I typed 'zsh' I was actually firing up 
the wrong version.