Re: Notes on zsh, zsh/files and recovery

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2008-10-19 at 01:39 -0500, Dan Nelson wrote:
> You mention FreeBSD later, so if something similar happens again, you
> should be able to use the statically-linked binaries in /rescue to
> recover from most shared-library problems, especially if you've got
> another system you can NFS-mount to copy files from.

For some reason, I thought a busted ld-elf.so.1 would break exec() of
any ELF binary, even static ones, as it was always in the path.
However, I neglected to even test it.  I'll blame it on the same
tiredness which made me completely forget about the existence of
/rescue.  I believe that the depth of feeling behind the "doh" as I read
your mail will make it less likely for me to forget in future.  Thanks.
:)

> In emergencies, I have used this as an ls replacement :)
> 
> ls() { echo ${@:-*} }

Yeah, "echo *" was the first thing I did, but I needed to see the size
and timestamps to figure out which files were affected.

function zls { local -A st; local f a='*'; [[ $# -eq 0 ]] && set -- *; for f ; do zstat -nsLH st $f; print -r -- "$st[mode] $st[nlink] ${(r:8:)st[uid]} ${(r:8:)st[gid]} ${(l:9:)st[size]} $st[name]" ; done }

I wrote that on the spot, aside from using stat instead of zstat, which
bit me when I tested it just now because I normally use:
  zmodload -F zsh/stat b:zstat
in my user account but I didn't bother with such niceties at the time,
as I no longer needed to worry about masking an external stat so just
loaded the whole module.

Obviously the fact that it only automatically lists all files when not
given a parameter, otherwise acting like "ls -d" is a slight downside,
but I got around that with zls dirname/* which was fine for me.  A
better zls would take -d as an option instead.

-Phil