Re: XCU, ls, OPTIONS, -F unclear (wants * /and/ @ for executable sockets)

[Oğuz via austin-group-l at The Open Group]

On Saturday, June 29, 2024, наб via austin-group-l at The Open Group <
austin-group-l@opengroup.org> wrote:
>
> This is a reasonable read I think.


XBD 3.129 describes an executable file as follows:

A regular file acceptable as a new process image file by the equivalent of
the exec family of functions, and thus usable as one form of a utility.

So, `executable' refers to the type of a file, not its having the execute
permission bit set.


-- 
Oğuz

Re: XCU, ls, OPTIONS, -F unclear (wants * /and/ @ for executable sockets)

[наб via austin-group-l at The Open Group]

(i did get the subject wrong of course, it'd be "= and * for executable 
sockets")


signature.asc
Description: PGP signature

XCU, ls, OPTIONS, -F unclear (wants * /and/ @ for executable sockets)

[наб via austin-group-l at The Open Group]

Hi!

Issue 8 XCU, ls, OPTIONS, -F says:
103308  −F  Do not follow symbolic links named as operands unless the −H or −L 
options are
103309  specified. Write a  ('/') immediately after each pathname 
that is a
103310  directory, an  ('*') after each that is executable, a 
 ('|')
103311  after each that is a FIFO, an  ('=') after each that 
is a socket, and a
103312   ('@') after each that is a symbolic link. For other 
file types, other
103313  symbols may be written.

This is unclear w.r.t. what's supposed to happen if a file is, say,
an executable FIFO.

STDOUT wants this to be one character,
so if we take this in the sentence order,
should executability then take precedent?
This is a reasonable read I think.

It's also wrong, all implementations apply the executableness test to
regular files only. This is also the only thing that really makes sense.

Should I forward this to a bug with a proposed resolution of
"replace »after each that is executable» with »after each regular file
that is executable»"?

Best,


signature.asc
Description: PGP signature