On 02/08/2025 10:43, Martin D Kealey wrote:
On Thu, 31 Jul 2025 at 07:51, Pádraig Brady <p...@draigbrady.com> wrote:
For consistency it probably makes sense for `chmod -h` to also
not follow a symlink given as --reference=.
I know mode bits are less supported on symlinks on various systems,
but for consistency it probably makes sense.
[and I wrote]
(functionality subject to whether the underlying FS supports
fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod),
Funny you should mention that; it's already in my patch set (wrapped in
#ifdef CAN_CHMOD_SYMLINK).
It would be best to not vary the user interface defaults
based on system features.But yes, it would be good to keep ch{mod,own,con}
interfaces in sync.
An alternative (or additional) approach would be to add new explicit
options (such as '--symlink-reference' and '--follow-reference') to all
of
the inode metadata manipulation commands including 'chcon', 'chgrp',
'chmod', 'chown', & 'touch'.
That would only be needed if mixing metadata between symlinks and non
symlinks, which I don't see as that useful.
I don't mean that those options would *only* take symlinks, rather that
they would be guaranteed to follow or not follow one if it happened to be
provided.
On the whole I prefer the suggestion to have
--no-dereference=[none|src|dest|all] except for the unnecessary negative.
I suggest «--derefence=[n[one]|s[rc]|d[est]|a[ll]]»
I agree --dererence=... would be best if implementing from scratch.
But given the existing --no-dereference, I would just extend that.
and the corresponding
version «-D[n|s|d|a]», with --no-dereference being a synonym for
«--dereference=none»/«-Dn» or «--dereference=src»/«-Ds» whichever matches
«-h» behaviour in each command.
(I'll grant that «-D*mode*» is a bit clunky, but it avoids a profusion of
new single-letter options, and I've often wished that cp, mv, ln, etc had
«-B*mode*» (corresponding to «--backup=*mode*», rather than just «-b».)
Interesting interface, but again I'm not sure another short option is warranted
here,
especially a short option taking an argument.
I had also been pondering adding --ref-prefix= where each target file would
obtain its reference from the corresponding file in another tree, which
would only really be useful with --recurse. (Doing that with internal
recursion would be a *lot* faster than, say «find . -type f -exec touch -h
--ref=/other/path/{} {} \;» since that needs a separate invocation of
«touch» for every target file.
Interesting. Though if only a performance benefit
as opposed to functionality benefit, it's less warranted.
That reminds me of the --pairs0-from suggestion at:
https://lists.gnu.org/archive/html/coreutils/2024-08/msg00019.html
In the same bucket of regularisation: every inode metadata command uses
«-c» to mean "verbose but only if it changes", EXCEPT «touch», where it's
"don't create". I don't suppose we could have a uniform
«--verbose=ifchanged»?
Interesting. Though touch doesn't have any --verbose option yet,
so I'm not convinced there is a pressing need for that?
Secondly, I note that 'touch -r' copies the atime and mtime separately;
it would be nice to be able to have --atime= and --mtime= as separate
options, as an alternative to both combined as --time=.
Again, I can provide a patch if this would be acceptable.
I don't understand this request.
Currently it takes two invocations of ‘touch’ to change the atime and mtime
to different values, UNLESS you're using -r in which case just one
invocation will suffice: touch -r copies the reference's mtime onto the
target's mtime, and the reference's atime onto the target's atime.
The idea would be to be able to perform this using explicit values for
atime and mtime separately rather than using a reference file.
Ah right. Given that's not often needed, and a perf only change,I'm not sure
that's warranted.
Thanks for taking the time to consider the touch interface so carefully.
cheers,
Padraig
