From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14056 invoked from network); 14 Dec 2000 14:43:26 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Dec 2000 14:43:26 -0000 Received: (qmail 25570 invoked by alias); 14 Dec 2000 14:43:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13274 Received: (qmail 25563 invoked from network); 14 Dec 2000 14:43:19 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) From: "Andrej Borsenkow" To: "Alexandre Duret-Lutz" Cc: Subject: RE: :r modifier Date: Thu, 14 Dec 2000 17:43:11 +0300 Message-ID: <000a01c065dc$2ea4d9e0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > No, under some older flavors of Unix, leading `//' is a > special path name: it refers to a "super-root" and is used to > access other machines' files. Leading `///', `////', etc. > are equivalent to `/'; but leading `//' is special. I think > this tradition started with Apollo Domain/OS, an OS that is > still in use on some older hosts. > I really liked Apollo Domain/OS. It was nice system, with transparent networking, remote execution and file system. You could start program on a second system with input from local (your own) and let output be created on a third. > POSIX.2 allows but does not require the special treatment for > `//'. It says that the behavior of dirname on path names of > the form `//([^/]+/*)?' is implementation defined. In these > cases, GNU `dirname' returns `/', but it's more portable to > return `//' as this works even on those older flavors of Unix. > Yep, POSIX is very careful to not require changing of existing behaviour. It prefers to leave most things as implementation defined. > > Andrej> I checked bash and it behaves the same as zsh. > > Huh? You aren't speaking about :h here, are you? > I am speaking about :r and :e. What so special about :h? Here is bash: mw1g017@MW1G17C ~ $ ls /bar/bar.baz/baz ls: /bar/bar.baz/baz: No such file or directory mw1g017@MW1G17C ~ $ ls !!:1:r ls /bar/bar ls: /bar/bar: No such file or directory mw1g017@MW1G17C ~ $ ls /bar/bar.baz/baz ls: /bar/bar.baz/baz: No such file or directory mw1g017@MW1G17C ~ $ ls !!:1:e ls .baz/baz ls: .baz/baz: No such file or directory Hmm ... with :e modifier bash preserves dot and zsh not. csh here behaves as zsh. Incidentally, csh here does treat strings like Alexander would like it: itsrm2% !21 echo /bar/bar.baz/baz /bar/bar.baz/baz itsrm2% echo !!:1:r echo /bar/bar.baz/baz /bar/bar.baz/baz itsrm2% echo !!:1:e echo -andrej