From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28207 invoked from network); 18 Oct 2008 20:56:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Oct 2008 20:56:43 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 94550 invoked from network); 18 Oct 2008 20:56:37 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Oct 2008 20:56:37 -0000 Received: (qmail 3582 invoked by alias); 18 Oct 2008 20:56:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25914 Received: (qmail 3565 invoked from network); 18 Oct 2008 20:56:25 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Oct 2008 20:56:25 -0000 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by bifrost.dotsrc.org (Postfix) with ESMTP id EDC3F80524C0 for ; Sat, 18 Oct 2008 22:56:09 +0200 (CEST) Received: by ug-out-1314.google.com with SMTP id y2so301517uge.18 for ; Sat, 18 Oct 2008 13:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cPY1jEq6LgbuyBXcGqt136UQ9SsrEIyzWCbMsEO5Jgo=; b=wcGmFn0pDAxA3RCwSXDur9Yu7vDxTvV/p5svkipmccctKCAwOQrPqfnHR4MQ9xM7R2 JkzWTvl6gjBrBAmzFGPtxMl2RCPxi3k+EtEYvs79T5Hx2bhejP2dfxHViDT3SXWUxfPR 51KsG/hOzmwY/eqtTMRlEoycfm5Ih1OwBg2YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=itI3l5nYrxQgPSg3jgprVIX3/ls+sHSv3Pci6pY/9lO4v2iAD7pNcWt1TvbKE0ENtt tqeaajK1AXienzZLkS6rIv4N64GVv+ZyXcTqUP79Z/SYQM9uzfM90v0xpzYdgOvogO3v LkKEk7Jsg4QI7akwbN9tcBVZo3SGQmYM53UkI= Received: by 10.210.16.17 with SMTP id 17mr6417154ebp.146.1224363368875; Sat, 18 Oct 2008 13:56:08 -0700 (PDT) Received: by 10.210.19.20 with HTTP; Sat, 18 Oct 2008 13:56:08 -0700 (PDT) Message-ID: <237967ef0810181356j7ff7a7d0g75890b89c81f271a@mail.gmail.com> Date: Sat, 18 Oct 2008 22:56:08 +0200 From: "Mikael Magnusson" To: zsh-workers@sunsite.dk Subject: Re: Notes on zsh, zsh/files and recovery In-Reply-To: <20081018204515.GA1642@redoubt.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081018204515.GA1642@redoubt.spodhuis.org> X-Virus-Scanned: ClamAV 0.92.1/8443/Sat Oct 18 08:08:31 2008 on bifrost X-Virus-Status: Clean 2008/10/18 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. In these situations, I usually find sash to come in handy. -- Mikael Magnusson