Notes on zsh, zsh/files and recovery

Notes on zsh, zsh/files and recovery

[Phil Pennock]

Managed to hose my box by trying to be too clever while rebuilding.
Luckily, had zsh as root at the time.  In the end, didn't help fix it;
once you've hosed /libexec/ld-elf.so.1 with a version that's for a
different architecture to the kernel, you're hosed.  But it's an
interesting exercise, trying to recover without making use of exec() (as
opposed to the more usual fork() limitation).

zsh/files needs zf_chmod.  I'll do that.  Not today, but when I've had
some sleep.  Does anyone have objections to platform-dependent commands
conditionally available in existing modules?  I'm tempted to add
chflags(1) too, since another time it might be a need to nuke an
immutable flag that's the problem.

I now see the use for zf_cp.  zmodload zsh/mapfile and using:
  print -nr -- ${mapfile[srcname]} > $destname
is a close approximation for a straight cat, at least.  Thankfully, zsh
handles embedded NULs fine.  Without chmod, copying an executable
cross-filesystem was trickier.  Luckily, for some reason, /bin/rmail is
still supplied on the root file-system in FreeBSD and that's
unimportant, so I could sacrifice it with zf_mv and then print mapfile
on top of it.  Alas, the only version I had available to recover with
was not helpful and there was no backup of the original and no way to
invoke an embedded C compiler from zsh.  *sigh*  Hrm, on reflection, if
I'd had another box to build on, I could have used zsh's built-in FTP
handling to retrieve the file that way.

Seem reasonable to implement zf_cp and make zf_mv call that for
cross-filesystem cases?

There does not appear to be a zls() ?  I hacked one together using
zsh/stat and ... it's rather slow.  I'm tempted to build up a closer
emulation of ls(1) with a few useful options and contribute it as a
standard function.  It will be truly slow, but occasionally useful.

If the ACL situation weren't such a complete mess across platforms, I
might do something there.  Anyone have any thoughts against
zsh/acl_posix1003.2c ?  Anyone have a better name?  ;)  I just want to
be able to use getfacl/setfacl and probably with the nice Linux
behaviour of automatically supplying a calculated mask for default
entries for setfacl, since the FreeBSD behaviour regularly bites me.
I've hit it often enough and use ACLs frequently enough now that I
think I remember quickly.  I can't think of a decent way to structure
the data of getfacl to have appropriate key/value for putting the
results into a hash, so it would only implement the regular support.

If I'm going to scratch this bunch of itches, anyone have any feature
requests or anti-feature requests?  No guarantees.

-Phil

Re: Notes on zsh, zsh/files and recovery

[Mikael Magnusson]

2008/10/18 Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>:
> Managed to hose my box by trying to be too clever while rebuilding.
> Luckily, had zsh as root at the time.  In the end, didn't help fix it;
> once you've hosed /libexec/ld-elf.so.1 with a version that's for a
> different architecture to the kernel, you're hosed.  But it's an
> interesting exercise, trying to recover without making use of exec() (as
> opposed to the more usual fork() limitation).
>
> zsh/files needs zf_chmod.  I'll do that.  Not today, but when I've had
> some sleep.  Does anyone have objections to platform-dependent commands
> conditionally available in existing modules?  I'm tempted to add
> chflags(1) too, since another time it might be a need to nuke an
> immutable flag that's the problem.
>
> I now see the use for zf_cp.  zmodload zsh/mapfile and using:
>  print -nr -- ${mapfile[srcname]} > $destname
> is a close approximation for a straight cat, at least.  Thankfully, zsh
> handles embedded NULs fine.  Without chmod, copying an executable
> cross-filesystem was trickier.  Luckily, for some reason, /bin/rmail is
> still supplied on the root file-system in FreeBSD and that's
> unimportant, so I could sacrifice it with zf_mv and then print mapfile
> on top of it.  Alas, the only version I had available to recover with
> was not helpful and there was no backup of the original and no way to
> invoke an embedded C compiler from zsh.  *sigh*  Hrm, on reflection, if
> I'd had another box to build on, I could have used zsh's built-in FTP
> handling to retrieve the file that way.
>
> Seem reasonable to implement zf_cp and make zf_mv call that for
> cross-filesystem cases?
>
> There does not appear to be a zls() ?  I hacked one together using
> zsh/stat and ... it's rather slow.  I'm tempted to build up a closer
> emulation of ls(1) with a few useful options and contribute it as a
> standard function.  It will be truly slow, but occasionally useful.
>
> If the ACL situation weren't such a complete mess across platforms, I
> might do something there.  Anyone have any thoughts against
> zsh/acl_posix1003.2c ?  Anyone have a better name?  ;)  I just want to
> be able to use getfacl/setfacl and probably with the nice Linux
> behaviour of automatically supplying a calculated mask for default
> entries for setfacl, since the FreeBSD behaviour regularly bites me.
> I've hit it often enough and use ACLs frequently enough now that I
> think I remember quickly.  I can't think of a decent way to structure
> the data of getfacl to have appropriate key/value for putting the
> results into a hash, so it would only implement the regular support.
>
> If I'm going to scratch this bunch of itches, anyone have any feature
> requests or anti-feature requests?  No guarantees.

In these situations, I usually find sash
<http://members.canb.auug.org.au/~dbell/programs/sash-3.7.tar.gz> to
come in handy.

-- 
Mikael Magnusson

Re: Notes on zsh, zsh/files and recovery

[Dan Nelson]

In the last episode (Oct 18), Phil Pennock said:
> Managed to hose my box by trying to be too clever while rebuilding.
> Luckily, had zsh as root at the time.  In the end, didn't help fix
> it; once you've hosed /libexec/ld-elf.so.1 with a version that's for
> a different architecture to the kernel, you're hosed.  But it's an
> interesting exercise, trying to recover without making use of exec()
> (as opposed to the more usual fork() limitation).

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.  Surprisingly, ftp
isn't in there, so if you need executables or libraries from
ftp.freebsd.org you'd have to ftp them from another box and copy them
via USB drive or something similar.
 
> There does not appear to be a zls() ?  I hacked one together using
> zsh/stat and ... it's rather slow.  I'm tempted to build up a closer
> emulation of ls(1) with a few useful options and contribute it as a
> standard function.  It will be truly slow, but occasionally useful.

In emergencies, I have used this as an ls replacement :)

ls() { echo ${@:-*} }

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Notes on zsh, zsh/files and recovery

[Phil Pennock]

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

Re: Notes on zsh, zsh/files and recovery

[Bart Schaefer]

On Oct 19,  5:28pm, Phil Pennock wrote:
} 
} Yeah, "echo *" was the first thing I did, but I needed to see the size
} and timestamps to figure out which files were affected.

If your complaint is about speed, a lot faster would probably be

zls () {
  local -a st
  local name dev inode mode nlink uid gid rdev
  local size atmim mtime ctme blksize blocks link
  [[ $# -eq 0 ]] && set -- *
  zstat -nsLA st "$@"
  for name dev inode mode nlink uid gid rdev \
      size atmim mtime ctme blksize blocks link \
    in "$st[@]"
  do print -r -- "$mode $nlink ${(r:8:)uid} ${(r:8:)gid} ${(l:9:)size} $name"
  done
}

Requires a recent enough zsh to have the multiple-assignment "for" syntax.