ntp@tf2.isl.mei.co.jp (Naoya TAKAO) (02/14/91)
I think the file test operators supplied with null string should always return an undefined value. I tried all the file test operations (except -M -A -C) with null string, on my home directory, and the operations that returned TRUE were:(perl@3.044, sun3/4.0.3 and solbourne(sun4/4.0.3 compatible)) -r, -w, -x, -o, -R, -W, -X, -O, -e, -s, -d, -B. I guess, "./" is added to the args of the file operators ? (I'm not sure, I couldn't find it in sources.) -- Naoya TAKAO (TAKAO is my family name) ntp@tf2.isl.mei.co.jp Matsushita Electric Industrial Co., Ltd.
tchrist@convex.COM (Tom Christiansen) (02/14/91)
From the keyboard of ntp@tf2.isl.mei.co.jp: :I think the file test operators supplied with null string should :always return an undefined value. : :I tried all the file test operations (except -M -A -C) with null :string, on my home directory, and the operations that returned TRUE :were:(perl@3.044, sun3/4.0.3 and solbourne(sun4/4.0.3 compatible)) : : -r, -w, -x, -o, -R, -W, -X, -O, -e, -s, -d, -B. : :I guess, "./" is added to the args of the file operators ? (I'm not :sure, I couldn't find it in sources.) Old-style systems (pre-POSIX) often treat the nullstring as the same as "." is many contexts. On my system, I can compile either way. In POSIX mode, things like (-d "") all return false. In non-POSIX mode, I get the behavior you're describing. --tom -- "All things are possible, but not all expedient." (in life, UNIX, and perl)