Hi kre,
> > if t=%f-$$.jpeg && ln %f "$t"; then (xv "$t"; rm "$t") & fi
> >
> > But appending to it destroys its suffix which needs re-creating with
> > a hard-cording.
>
> not so much:
>
> t=%f ; suf=${t##*.} ; t=${t%.${suf}} ; t="$t-$$.$suf" ; ln %f "$t" && ....
‘t=${t%.${suf}}’ will interpret globs in $suf, not that I can see globs
causing a problem in this case. The simpler ‘t=${t%.*}’ avoids this,
and seems idiomatic to me because it's what I normally do. :-)
> which should work given it is assuming that %f must have a suffix in
> order for this to be invoked.
You're quite right, it can be coped with. Though I went looking for problems,
and wondered about suffixes like .tar.gz suffixes so concocted:
$ grep foo.bar ~/.mh_profile
mhshow-suffix-foo/bar: .foo.bar
mhshow-show-foo/bar: %lwc '%f' 2>&1
mhstore-store-foo/bar: %m%P.foo.bar
$
$ mhlist
msg part type/subtype size description
145377 foo/bar 46
charset="utf-8"
$ mhstore
storing message 145377 as file 145377.foo.bar
$ mhshow
[ Message inbox:145377 ]
(Message 145377)
from: R
to: R
date: Sat, 27 Sep 2025 13:24:56 +0000
[ part - foo/bar - 46B ]
1 2 46 /home/ralph/mail/mhshowzToPU8.foo.bar
$
> Also unless there is a command substitution involved (none in any
> of these variations) there's never any point in testing whether a variable
> assignment worked or not (as in checking its exit status). Those *never*
> fail (unless the shell runs out of memory, in which case you're screwed),
> so testing the status is pointless.
If out of memory, I'd like to stop rather than push on with bad data.
The ‘${t?}’ tests fail, not that I wrote one of those. ‘d=~’ is
unspecified if $HOME isn't set, and ‘d=~foo’ undefined if the login name
is unknown.
> ps: personally I prefer copying the file, doing so avoids complications
> should the original file be modified to contain something different later.
I never considered that. Yes, an rmm then inc could replace message 42.
One starts to think of mk*temp(3) solutions, or just ‘user beware’.
--
Cheers, Ralph.
