# Plain POSIX sh
#! /bin/sh
git status >/dev/null || exit
if ! git diff-index --quiet HEAD; then
echo 'Working dir not clean' >&2
exit 1
fi
find . -name .git -prune \
-o -exec sh -c '
# Ask Git for latest commit'\''s timestamp,
# formatted for POSIX '\''touch -t'\''.
timestamp=$(git log --format=%cd \
--date=format:%Y%m%d%H%M.%S \
-1 HEAD -- "$1") || exit
[ -n "$timestamp" ] || exit
set -x
touch -t "$timestamp" "$1"
' dummy {} \;
#! /usr/bin/env modernish
#! use safe
#! use sys/cmd/harden
#! use var/loop
harden git
harden -e '>1' -f wd_is_clean \
git diff-index --quiet HEAD
harden -pt touch
git status >/dev/null
wd_is_clean || exit 1 'Working dir not clean'
total=0
LOOP find repofile in . -name .git -prune \
-or -iterate; DO
# Ask Git for latest commit's timestamp,
# formatted for POSIX 'touch -t'.
timestamp=$(git log --format=%cd \
--date=format:%Y%m%d%H%M.%S \
-1 HEAD -- $repofile)
str empty $timestamp && continue
# 'touch' is traced by 'harden -t'.
touch -t $timestamp $repofile
let "total+=1"
DONE
exit 0 "$total timestamps restored."for myself, if i want a shell script to be _portable_ i just write it in POSIX sh and try to be smart about dependencies
and if i don't care about portability, i'd rather just use a nicer shell like bash or zsh or fish (i'd actually like to mess with ysh at some point)
i feel like i'm much more likely to encounter a system with one of those shells available than one with modernish installed, and the idea of introducing a bundling/build step into shell scripts is deeply unappealing to me.
i can see why this exists, i think, and i imagine there are people who find it useful. i simply am not among them.
i also find it disappointing that their most basic example shows the setup in bash instead of sh, but that might just be me.
A very old and beloved pig, but still alas, a pig.
It's great to extend the shell idiom, to patch up its inconsistencies and unportabilites, to make it better. I love the progression of sh, csh, tcsh, ksh, bash, zsh, fish, and others. But it's also Sisyphean. At the end, you still have a shell experience not a programming language experience. And as long as we're talking about programming things, the full toolset will remain more direct, more powerful, more maintainable—and thus more apt.
I hate gol-lumping over the gap between a dashed-off Bash or Zsh script and the Python equivalent (say), but the full language has better semantics, typing, exceptions, modules, data structures, expressive power, and tooling. As the person who not only has to dash off the initial POC but extend and maintain it over time, and someone who's tried both routes, if there's any complexity at all—any datetimes, timestamps, or timezones to be wrangled; any complex JSON to be parsed out of an API; any significant parsing or concurrency to be managed—going to prefer the full tools every time.
Nushell fixes this: https://nushell.sh/
I've been using it as my shell for 2-3 years, and it has improved a LOT since then. The interactive experience is great, and it's wonderful assembling scripts in its REPL. I can use my editor to edit the bufferline too using ctrl+o.
The best thing about it is that's it's self-contained. You don't have to assume anything about the users environment, as Nushell has almost everything you'd need fot common tasks built-in.
Some example scripts I've written:
- Link all files in a dir & deduplicate based on hash, in parallel, handling all cases: https://github.com/RGBCube/random-scripts/blob/master/linear... - A simple github->forgejo migration/live mirroring script: https://github.com/RGBCube/GitHub2Forgejo/blob/master/github...
All of these only need nushell, and not even coreutils.
pimlottc•6mo ago