Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: cd -q (was Re: _canonical_path ...)
- X-seq: zsh-workers 24763
- From: "Mikael Magnusson" <mikachu@xxxxxxxxx>
- To: "Peter Stephenson" <pws@xxxxxxx>
- Subject: Re: PATCH: cd -q (was Re: _canonical_path ...)
- Date: Thu, 27 Mar 2008 13:35:46 +0100
- Cc: zsh-workers@xxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kR/QihyAEaNhPtl07g6D5OUoUsM6E9AwL09RSEwF24Y=; b=Ht+5jo7JZ86jPo0Uw+Qk9Jiio27355TITE89Bfwebri6gueAnzzc0DknSFKrurBTJfx0UMJexeE2BUZmk6elR390bl2FdNvYdcfkPH708M/DJu0BepJPmBViVFfc/V0LwtZlO8iIIJjRsftExDNiQJtcmRgzI/fgtEmWQnd9umc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ovRCNIEzPVV9dIq3Z5Fa2M41sSopkrrc/AcHS6QQvbD9wP+Q8OxE4MGU1OKh8jmcGCKLar/1MlJPMtONLewZfy9UGn0q+hz/Q+LvAzaO553d41BEXRWQ1PaliZQvkPh+cfiOtPk+Gx51jBxI0lKKCx++bMDCrroT4lGpcuKkyT4=
- In-reply-to: <20080327121525.5b4059f9@news01>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20080326114413.80713vrmznwpnyuc@xxxxxxxxxxxxxxx> <200803261540.m2QFeJmm017381@xxxxxxxxxxxxxx> <200803261604.m2QG41Ke017772@xxxxxxxxxxxxxx> <200803261621.m2QGLptV017966@xxxxxxxxxxxxxx> <20080326173824.0a55c00d@xxxxxxxxxxxxxxxxxxxxxx> <20080326164615.1d5893ed@news01> <20080327102325.55808716@news01> <20080327120807.415095ee@xxxxxxxxxxxx> <20080327112506.7298e9ef@news01> <20080327121525.5b4059f9@news01>
On 27/03/2008, Peter Stephenson <pws@xxxxxxx> wrote:
> The more I think about this (and I'd really like to stop now), the more
> wrong it seems to me that it's so hard to get the shell to cd without
> side effects. Indeed, the patch above is incomplete since it omits
> the new chpwd_functions array, and I haven't work out a foolproof
> way of suppressing the effect of chpwd without forking the shell.
> chpwd will typically print a bogus directory to the terminal title
> bar, which is to be avoided; but it can in principle do anything
> and if we're not sticking around in the directory the interactive
> environment really doesn't need to care about the cd.
>
> Any comments about the following proposal, which adds the -q option
> to all relevant functions? If it looks OK, I'll change the function
> above to unsetopt PUSHD_NO_DUPS and use pushd -q/popd -q to sanitize
> the directory with REPLY=$PWD and remove the fork.
Nice, I've wanted this on several occasions. Especially since
sometimes my chpwd function breaks constructs like (cd /foo; tar c .)
| tar x. I worked around that by printing everything to stderr instead
but it seems icky.
Also, I realized I didn't know what the existing options -sLP did, so
I looked at the manpage and
1) there's a typo near the beginning
Otherwise, if var(arg) begins with a slash, attempt to change to the
director<missing a y here> given by var(arg).
2)
If the -P option is given or the CHASE_LINKS option is set,
symbolic links are resolved to their true values. If the -L option
is given symbolic links are followed regardless of the state of the
CHASE_LINKS option.
Intuitively this paragraph doesn't make any sense. Both options seem
to do the same thing? (-P || CHASE_LINKS) || -L == -P || -L ||
CHASE_LINKS
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author