This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 437750 - gawk complains about directory args
gawk complains about directory args
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gawk (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 04:26 EDT by JW
Modified: 2008-11-08 08:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-08 08:05:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JW 2008-03-17 04:26:43 EDT
Description of problem:
An directory arg stops processing

Version-Release number of selected component (if applicable):
gawk-3.1.5-15

How reproducible:
Always

Steps to Reproduce:
1. In an empty directory ...
2. for f in a c e; do echo >$f; done
3. mkdir b
4. awk --compat '{print FILENAME}' *

Actual results:
a
awk: cmd. line:1: fatal: file `b' is a directory

Expected results:
a
c
e

Additional info:
The existence of a directory might produce a warning on stderr but it certainly
shouldn't stop processing of other files.  Mainly because it is a HUGE
incovenience if you have a directory of 1000 files and one sub-directory and you
have to resort to some weird command like: awk '{print FILENAME}' `find .
-maxdepth 1 -type f`

On SunOS and many other unix's traditional awk silently skips directories, which
is very sensible behavior indeed.  Because if awk doesn't process a directory
(it cannot) and therefore doesn't do anything with it (it cannot) then why
should it loudly proclaim an error and completely abort?  It is quite safe to
continue processing other args because the directory is not affected one way or
another.

Look at any other programs and see how directories are handled. None of vi, wc,
cat, etc completely abort processing just because they encounter a directory.

This also happens regardless of use of --compat option. Despite the
documentation claiming "... in compatibility mode, gawk behaves identically to
UNIX awk ...". That is clearly untrue.
Comment 1 Denys Vlasenko 2008-07-14 10:57:03 EDT
Testing latest released upstream version:

Seems like gawk 3.1.6 can be made to continue on directory errors with
--disable-directories-fatal configure switch, do we want to build it for RH that
way?

> This also happens regardless of use of --compat option...

Indeed it does in 3.1.5, but 3.1.6 seems to have that fixed.

Just tested 3.1.6 with --compat and with --traditional and it works with both -
directories are silently ignored.
Comment 2 Stepan Kasal 2008-10-31 07:02:33 EDT
Indeed, you are right.  I will build gawk with --disable-directories-fatal.
Note that grep does the same: silently ignores directories.
Comment 3 Stepan Kasal 2008-10-31 08:52:57 EDT
answering to myself:
> Note that grep does the same: silently ignores directories.

This was a silly note.  Most utilities do complain, try
  sed -n p /tmp /etc/hosts
Comment 4 Stepan Kasal 2008-11-08 08:04:10 EST
The POSIX standard implies the current behaviour.  Quoting from http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html#tag_04_06_15:

CONSEQUENCES OF ERRORS
If any file operand is specified and the named file cannot be accessed, awk shall write a diagnostic message to standard error and terminate without any further action.
--end of quote--

So, on current GNU/Linux system, where it is not possible to open a directory for reading, awk has not option other then to print an error and immediately quit.

Note You need to log in before you can comment on or make changes to this bug.