zsh tests (dev-15)

zsh tests (dev-15)

[Oliver Kiddle]

I've never looked at the new tests before but thought I'd run them
today. They all pass except one in 07cond.ztst: [[ -e /dev/fd/0 ]]
fails. I thought that this /dev/fd/0 stuff was Linux specific (I'm using
AIX 3.2) so what is it doing as part of the zsh tests? Is zsh trying to
emulate them on other systems? If so, maybe AIX's /dev/fd0 and similar
devices (which I think are for the floppy drive) are getting in the way?

Oliver Kiddle

Re: zsh tests (dev-15)

[Clint Adams]

> fails. I thought that this /dev/fd/0 stuff was Linux specific (I'm using

It's not.  Solaris and BSDs have it, at least.

Re: zsh tests (dev-15)

[Peter Stephenson]

Oliver Kiddle wrote:
> I've never looked at the new tests before but thought I'd run them
> today. They all pass except one in 07cond.ztst: [[ -e /dev/fd/0 ]]
> fails. I thought that this /dev/fd/0 stuff was Linux specific (I'm using
> AIX 3.2) so what is it doing as part of the zsh tests? Is zsh trying to
> emulate them on other systems? If so, maybe AIX's /dev/fd0 and similar
> devices (which I think are for the floppy drive) are getting in the way?

Yes, it's supposed to be emulated:  the conditional expressions part of the
manual says:

       In each of the above expressions, if file is of  the  form
       `/dev/fd/n',  where n is an integer, then the test applied
       to the open file whose descriptor number is n, even if the
       underlying  system does not support the /dev/fd directory.

so something on your system is confusing it (unless, of course, you're
really running the test with no stdin).  There's a run-time test for
this in cond.c:getstat():

/* /dev/fd/n refers to the open file descriptor n.  We always use fstat *
 * in this case since on Solaris /dev/fd/n is a device special file     */
    if (!strncmp(s, "/dev/fd/", 8)) {
	if (fstat(atoi(s + 8), &st))
	    return NULL;
        return &st;
    }

There doesn't look to be much to go wrong, but somehow you seem to be
getting NULL here.  (Actually, there's a lie in the manual page since the
code doesn't care if there's an integer next or not, but it's not
disastrous.)

I'd appreciate any help I can get with system-specific fixes for the tests,
I'm pretty much limited to Linux most of the time at the moment.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

PATCH: Re: zsh tests (dev-15)

[Oliver Kiddle]

Sorry, I only now got around to looking into this.

Back on Jan 15th, Peter Stephenson wrote:
> 
> Oliver Kiddle wrote:
> > I've never looked at the new tests before but thought I'd run them
> > today. They all pass except one in 07cond.ztst: [[ -e /dev/fd/0 ]]
> > fails. I thought that this /dev/fd/0 stuff was Linux specific (I'm using
> > AIX 3.2) so what is it doing as part of the zsh tests? Is zsh trying to
> > emulate them on other systems? If so, maybe AIX's /dev/fd0 and similar
> > devices (which I think are for the floppy drive) are getting in the way?
> 
> Yes, it's supposed to be emulated:  the conditional expressions part of the
> manual says:
> 
>        In each of the above expressions, if file is of  the  form
>        `/dev/fd/n',  where n is an integer, then the test applied
>        to the open file whose descriptor number is n, even if the
>        underlying  system does not support the /dev/fd directory.
> 
> so something on your system is confusing it (unless, of course, you're
> really running the test with no stdin).  There's a run-time test for
> this in cond.c:getstat():

The code never reaches getstat() with a -e test. If you look at the big
case statement in cond.c, lines numbered in the 200s, for e, it uses
doaccess. getstat() appears to be used for -O, -G, -N, whatever COND_NT,
COND_OT and COND_EF are and all the options which go via dostat(). Those
using doaccess(), miss out the test Peter refered to in getstat().

The patch below extends emulation of /dev/fd/n to the -a, -e, -r, -w and
-x options.

After a quick look at some man pages, it seems that Linux maybe doesn't
have faccessx(). Is this right? Is there an alternative? Does anyone
know if there are any platforms which don't have faccessx or /dev/fd/x
because if not, we could easily wrap my changes to doaccess() in a
#ifdef after detecting faccessx with autoconf. Am I right to use
ACC_SELF instead of ACC_INVOKER (see
http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf1/access.htm)?

Oliver Kiddle

--- Src/cond.c.bak	Sat Mar 11 20:13:28 2000
+++ Src/cond.c	Sat Mar 11 20:13:34 2000
@@ -297,6 +297,9 @@
 static int
 doaccess(char *s, int c)
 {
+    if (!strncmp(s, "/dev/fd/", 8))
+	return !faccessx(atoi(s + 8), c, ACC_SELF);
+
     return !access(unmeta(s), c);
 }

Re: PATCH: Re: zsh tests (dev-15)

[Bart Schaefer]

On Mar 11,  8:41pm, Oliver Kiddle wrote:
} Subject: PATCH: Re: zsh tests (dev-15)
}
} After a quick look at some man pages, it seems that Linux maybe doesn't
} have faccessx(). Is this right? Is there an alternative? Does anyone
} know if there are any platforms which don't have faccessx

I found the following on a Google-cached copy of a web page about hacking
into linux systems by exploiting "find ... -exec rm {} \;" as run by cron.
It would appear that faccess() and faccessx() [and by extension probably
accessx() as well] are strictly IBM-isms.

----------------------------------------------------------------

Here is a comparison of some related calls between various OSes:

           Linux*    AIX 3.2   Sunos 4.1.3   Solaris 2.5

chown()      Y          Y          Y            Y                    
fchown()     Y          Y          Y            Y
lchown()     N          N          N            Y

chmod()      Y          Y          Y            Y
fchmod()     Y          Y          Y            Y
lchmod()     N          N          N            N

stat()       Y          Y          Y            Y
lstat()      Y          Y          Y            Y
fstat()      Y          Y          Y            Y
fstatx()     N          Y          N            N
flstat()     N          N          N            N

access()     Y          Y          Y            Y
faccess()    N          Y          N            N
faccessx()   N          Y          N            N

----------------------------------------------------------------


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: Re: PATCH: Re: zsh tests (dev-15)

[Bart Schaefer]

On Mar 11,  8:41pm, Oliver Kiddle wrote:
} Subject: PATCH: Re: zsh tests (dev-15)
}
} After a quick look at some man pages, it seems that Linux maybe doesn't
} have faccessx(). Is this right?

Here's a follow-up patch to test for faccessx() and omit Oliver's bit
if it isn't found.  I've taken the liberty of rearranging the function
list for AC_CHECK_FUNCS a bit so that related things are grouped, after
a fashion.

I've kept the backslash at the end of every line, but are those really
necessary?  I thought m4 would do the right thing with macro arguments
that span multiple lines.

Index: configure.in
===================================================================
@@ -802,22 +802,33 @@
 #include <netinet/in.h>
 ], struct sockaddr_in6, sin6_scope_id)
 
+dnl ---------------
+dnl CHECK FUNCTIONS
+dnl ---------------
+
 dnl need to integrate this function
 dnl AC_FUNC_STRFTIME
 
-AC_CHECK_FUNCS(lchown memcpy memmove \
-              strftime waitpid select poll tcsetpgrp tcgetattr strstr lstat \
-              getlogin setpgid gettimeofday gethostname mkfifo wait3 difftime \
-              sigblock sigsetmask sigrelse sighold killpg sigaction getrlimit \
-              sigprocmask setuid seteuid setreuid setresuid setsid strerror \
-              nis_list initgroups fchdir cap_get_proc readlink nice \
-	      getgrgid getgrnam getpwent getpwnam getpwuid setpgrp \
-	      inet_aton inet_pton inet_ntop getipnodebyname gethostbyname2 \
-	      fseeko ftello mmap munmap msync ftruncate setlocale _mktemp)
+AC_CHECK_FUNCS(strftime difftime gettimeofday \
+	       select poll \
+	       readlink lstat lchown faccessx fchdir ftruncate \
+	       fseeko ftello \
+	       mkfifo _mktemp \
+	       waitpid wait3 \
+	       sigaction sigblock sighold sigrelse sigsetmask sigprocmask \
+	       killpg setpgid setpgrp tcsetpgrp tcgetattr nice \
+	       gethostname gethostbyname2 getipnodebyname \
+	       inet_aton inet_pton inet_ntop \
+	       getlogin getpwent getpwnam getpwuid getgrgid getgrnam \
+	       initgroups nis_list \
+	       setuid seteuid setreuid setresuid setsid \
+	       memcpy memmove strstr strerror \
+	       mmap munmap msync \
+	       cap_get_proc \
+	       getrlimit \
+	       setlocale)
+AC_FUNC_STRCOLL
 
-dnl ---------------
-dnl CHECK FUNCTIONS
-dnl ---------------
 if test $ac_cv_func_setpgrp = yes; then
   AC_FUNC_GETPGRP
 else
@@ -828,7 +839,6 @@
   ac_cv_func_getpgrp_void=yes
   AC_DEFINE(GETPGRP_VOID)
 fi
-AC_FUNC_STRCOLL
 
 if test $dynamic = yes; then
   AC_CHECK_FUNCS(dlopen dlerror dlsym dlclose load loadquery loadbind unload \
Index: Src/cond.c
===================================================================
@@ -310,9 +310,10 @@
 static int
 doaccess(char *s, int c)
 {
+#ifdef HAVE_FACCESSX
     if (!strncmp(s, "/dev/fd/", 8))
 	return !faccessx(atoi(s + 8), c, ACC_SELF);
-
+#endif
     return !access(unmeta(s), c);
 }
 

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Re: PATCH: Re: zsh tests (dev-15)

[Zefram]

Bart Schaefer wrote:
>I've kept the backslash at the end of every line, but are those really
>necessary?

Yes.

>            I thought m4 would do the right thing with macro arguments
>that span multiple lines.

It does.  m4 treats the backslashes as normal characters; it's a macro
argument that contains several newlines.  That particular argument
ultimately ends up in the configure script, with newlines intact, in a
context where a single line is required by the shell syntax (have a look).
The backslashes are there to make /bin/sh happy about the newlines.

-zefram