glob() bug 
Author Message
 glob() bug

glob doesn't work if STDIN, STDOUT and STDERR are closed. Why?

Short snippet example:

#! /usr/local/bin/perl
close STDIN; close STDOUT; close STDERR; # works if this line is commented out
chop($x = `echo /hp*`);
exec("hpterm -e echo foo $x bar\n");

I can tell by tracing that it calls csh (of all things) to do the globbing,
but what do 0, 1 and 2 have to do with that?

(The real script is being called from CGI where the fds are actually closed)

    -Kartik



Sat, 19 Jul 1997 08:46:07 GMT  
 glob() bug

Quote:

>glob doesn't work if STDIN, STDOUT and STDERR are closed. Why?

Only a problem when STDIN is closed.  Closing STDOUT and STDERR doesn't
seem to make any difference.

Quote:
>I can tell by tracing that it calls csh (of all things) to do the globbing,
>but what do 0, 1 and 2 have to do with that?

If I run the following script, something strange happens:

I get the string "/hp-ux" on STDERR, and $expn is empty.  If I comment
out the close, $expn contains the string "/hp-ux", as I would expect.

#!/usr/local/bin/perl
close STDIN;
$expn = </hp*>;
__END__

In looking at trace output (for s300, maybe different than s700), I
noticed that csh appears to make some assumptions about file
descriptors 0, 1, and 2.  Since 0 (STDIN) has been closed, it will be
used again for the next open file.  Perhaps this confuses someone
(perl or csh)?

I don't know exactly what is going on here, but it seems to me that
it is time for perl to do its own globbing.
--
Rodger Anderson



Sat, 19 Jul 1997 12:21:45 GMT  
 glob() bug
: #!/usr/local/bin/perl
: close STDIN;
: $expn = </hp*>;
: __END__
:
: In looking at trace output (for s300, maybe different than s700), I
: noticed that csh appears to make some assumptions about file
: descriptors 0, 1, and 2.  Since 0 (STDIN) has been closed, it will be
: used again for the next open file.  Perhaps this confuses someone
: (perl or csh)?

Many standard Unix utilities will get confused if you hand them closed
fds 0, 1, or 2.  It's considered vaguely antisocial to do so.  The
usual workaround is to open /dev/null instead of closing.

: I don't know exactly what is going on here, but it seems to me that
: it is time for perl to do its own globbing.

It's time for Perl to do a lot of things.  Unfortunately, I can only
work on one of them at once, max.  If I were going to work on it, I'd
probably take a globbing Perl module and stitch it in to get called
transparently by <*>.  In this sense, Perl should *not* do its own
globbing, but should rely on (potentially architecture dependent)
modules to do so.  We already did something similar with the
implementation of dbmopen.

Speaking of which, anybody want to hack up a DBZ_File module?

Larry



Tue, 22 Jul 1997 01:17:38 GMT  
 glob() bug

Quote:


>: #!/usr/local/bin/perl
>: close STDIN;
>: $expn = </hp*>;
>: __END__
>:
>: In looking at trace output (for s300, maybe different than s700), I
>: noticed that csh appears to make some assumptions about file
>: descriptors 0, 1, and 2.  Since 0 (STDIN) has been closed, it will be
>: used again for the next open file.  Perhaps this confuses someone
>: (perl or csh)?

>Many standard Unix utilities will get confused if you hand them closed
>fds 0, 1, or 2.  It's considered vaguely antisocial to do so.  The
>usual workaround is to open /dev/null instead of closing.

>: I don't know exactly what is going on here, but it seems to me that
>: it is time for perl to do its own globbing.

>It's time for Perl to do a lot of things.  Unfortunately, I can only
>work on one of them at once, max.  If I were going to work on it, I'd
>probably take a globbing Perl module and stitch it in to get called
>transparently by <*>.  In this sense, Perl should *not* do its own
>globbing, but should rely on (potentially architecture dependent)
>modules to do so.  We already did something similar with the
>implementation of dbmopen.

Umm, a quick peek at the Perl 5 Module List shows:

=======================================================================
File Names, File Systems, File Locking and File Handles

Name           DSLI  Description                                  Info
-----------    ----  -------------------------------------------- -----
File::
::KGlob        cdcf  Filename globing (ksh style)                 TYEMQ

=======================================================================
Information / Contact Reference Details (in alphabetical order)

Ref    Contact Details
-----  ------------------------------------------------------

From memory Perl 5 has a 'glob' function which the File::KGlob module
can override if desired. Sadly, in Perl5.000, the <*> shorthand does
not use the glob function and hence can not be overridden by the
File::KGlob module.

That may change in Perl5.00x. I don't know if Larry regards it as a bug.

Quote:

>Larry

Regards,
Tim Bunce.


Tue, 22 Jul 1997 02:53:36 GMT  
 glob() bug

Quote:

>In this sense, Perl should *not* do its own
>globbing, but should rely on (potentially architecture dependent)
>modules to do so.  We already did something similar with the
>implementation of dbmopen.

>Speaking of which, anybody want to hack up a DBZ_File module?

This reminds me of a question I've been meaning to ask for a while:

How difficult is it to use dbz as a replacement for dbm with perl4?

I'm relatively new to perl, and I'm currently using its dbm support
via associative arrays, which is incredibly easy. This is an excellent
feature of Perl, but unfortunately the dbm files end up being too big.
(I know they aren't as big as they look, but the real usage is also big).

Does anyone have a (preferably easy, drop-in) solution for this? Thanks,

Gerald
--
http://ugweb.cs.ualberta.ca/~gerald/



Wed, 23 Jul 1997 04:15:09 GMT  
 glob() bug

Quote:


>>In this sense, Perl should *not* do its own
>>globbing, but should rely on (potentially architecture dependent)
>>modules to do so.  We already did something similar with the
>>implementation of dbmopen.

>>Speaking of which, anybody want to hack up a DBZ_File module?

>This reminds me of a question I've been meaning to ask for a while:

>How difficult is it to use dbz as a replacement for dbm with perl4?

>I'm relatively new to perl, and I'm currently using its dbm support
>via associative arrays, which is incredibly easy. This is an excellent
>feature of Perl, but unfortunately the dbm files end up being too big.
>(I know they aren't as big as they look, but the real usage is also big).

>Does anyone have a (preferably easy, drop-in) solution for this? Thanks,

>Gerald
>--
>http://ugweb.cs.ualberta.ca/~gerald/

The Perl 5 Modules List says:

=======================================================================
Database Interfaces (see also Data Types)

Name           DSLI  Description                                  Info
-----------    ----  -------------------------------------------- -----
NDBM_File      Suc   Tie interface to NDBM files
DB_File        Suc   Tie interface to DB files                    PMQS
GDBM_File      Suc   Tie interface to GDBM files
SDBM_File      Suc   Tie interface to SDBM files
ODBM_File      Suc   Tie interface to ODBM files
AnyDBM_File    Sup   Uses first available *_File module above
DBZ_File       iuc   Tie interface to dbz files.                  IANPX

Ref    Contact Details
-----  ------------------------------------------------------

Regards,
Tim Bunce.



Fri, 25 Jul 1997 18:00:52 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. glob() bug or feature ??

2. per5.0001 and glob (bug?) under linux (with satan)

3. Small bug in glob.pl

4. FAQ: Is there a leak/bug in glob()?

5. FAQ: Is there a leak/bug in glob()?

6. FAQ: Is there a leak/bug in glob()?

7. FAQ: Is there a leak/bug in glob()?

8. FAQ: Is there a leak/bug in glob()?

9. FAQ: Is there a leak/bug in glob()?

10. FAQ: Is there a leak/bug in glob()?

11. globs and truncate bug?

12. GLOB ref bug in FileHandle::DESTROY

 

 
Powered by phpBB® Forum Software