Test failures in coreutils-5.3.0 on cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The 5.3.0 testsuite does not even get a chance to run on cygwin, because
the check-README target of src/Makefile does not take into account
${EXEEXT}. See the attached coreutils.check, and my proposed patch below.
However, I didn't have automake 1.9.4, and could not get `autoreconf
- -fiv' to incorporate my patch (undistributed gnulib files, or an
incomplete ACLOCAL_AMFLAGS, perhaps?), see the attached coreutils.check2.
Once I manually patched the corresponding Makefile.ins, I don't get very
far into the testsuite (1 of 5 failed under tests/chgrp), see
coreutils.check3. I haven't yet had time to figure out how to get any
further.
2005-01-11 Eric Blake [EMAIL PROTECTED]
* src/Makefile.am (check-README, check-AUTHORS): Account for
$(EXEEXT).
* man/Makefile.am (all_programs): Account for $(EXEEXT).
- --- src/Makefile.am~2004-12-14 16:52:44.0 -0700
+++ src/Makefile.am 2005-01-11 06:50:32.46825 -0700
@@ -239,7 +239,8 @@
check-README:
rm -rf $(pr) $(pm)
echo $(all_programs) \
- - | tr -s ' ' '\n' | $(ASSORT) -u $(pm) \
+ | tr -s ' ' '\n' | sed -e 's,$(EXEEXT)$$,,' \
+ | $(ASSORT) -u $(pm) \
sed -n '/^The programs .* are:/,/^[a-zA-Z]/p' $(top_srcdir)/README \
| sed -n '/^ */s///p' | tr -s ' ' '\n' $(pr)
diff $(pm) $(pr) rm -rf $(pr) $(pm)
@@ -250,7 +251,8 @@
.PHONY: check-AUTHORS
check-AUTHORS: $(all_programs)
rm -f $(au_actual) $(au_dotdot)
- - for i in `ls $(all_programs) | $(ASSORT) -u`; do \
+ for i in `ls $(all_programs) | sed -e 's,$(EXEEXT)$$,,' \
+ | $(ASSORT) -u`; do \
test $$i = '[' continue; \
exe=$$i; \
if test $$i = install; then \
- --- man/Makefile.am~2004-11-25 05:33:13.0 -0700
+++ man/Makefile.am 2005-01-11 06:55:01.96825 -0700
@@ -155,7 +155,7 @@
all_programs = \
(cd ../src MAKEFLAGS= $(MAKE) -s all_programs.list) \
- -| grep -v '\['
+| sed -e 's,$(EXEEXT)$$,,' | grep -v '\['
.PHONY: check-programs-vs-x
check-programs-vs-x:
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB496I84KuGfSFAYARAj15AJ4wooi8+mnPYuvom2RvR5Bzm/plJwCfdzhv
dIY0HWPDRAi2gnf4QWyY1AA=
=Ac2l
-END PGP SIGNATURE-
Making check in lib
make[1]: Entering directory `/home/eblake/coreutils-5.3.0/lib'
./t-fpending /dev/null
make check-am
make[2]: Entering directory `/home/eblake/coreutils-5.3.0/lib'
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory `/home/eblake/coreutils-5.3.0/lib'
make[1]: Leaving directory `/home/eblake/coreutils-5.3.0/lib'
Making check in src
make[1]: Entering directory `/home/eblake/coreutils-5.3.0/src'
rm -rf progs-readme progs-makefile
echo [.exe chgrp.exe chown.exe chmod.exe cp.exe dd.exe dircolors.exe du.exe
ginstall.exe link.exe ln.exe dir.exe vdir.exe ls.exe mkdir.exe mkfifo.exe
mknod.exe mv.exe nohup.exe readlink.exe rm.exe rmdir.exe shred.exe stat.exe
sync.exe touch.exe unlink.exe cat.exe cksum.exe comm.exe csplit.exe cut.exe
expand.exe fmt.exe fold.exe head.exe join.exe md5sum.exe nl.exe od.exe
paste.exe pr.exe ptx.exe sha1sum.exe sort.exe split.exe sum.exe tac.exe
tail.exe tr.exe tsort.exe unexpand.exe uniq.exe wc.exe basename.exe date.exe
dirname.exe echo.exe env.exe expr.exe factor.exe false.exe hostname.exe id.exe
kill.exe logname.exe pathchk.exe printenv.exe printf.exe pwd.exe seq.exe
sleep.exe tee.exe test.exe true.exe tty.exe whoami.exe yes.exe uname.exe
chroot.exe hostid.exe nice.exe pinky.exe users.exe who.exe uptime.exe stty.exe
df.exe groups chroot.exe df.exe hostid.exe nice.exe pinky.exe stty.exe su.exe
uname.exe uptime.exe users.exe who.exe \
| tr -s ' ' '\n' | LC_ALL=C sort -u progs-makefile \
sed -n '/^The programs .* are:/,/^[a-zA-Z]/p' ../README \
| sed -n '/^ */s///p' | tr -s ' ' '\n' progs-readme
diff progs-makefile progs-readme rm -rf progs-readme progs-makefile
1,28c1,28
[.exe
basename.exe
cat.exe
chgrp.exe
chmod.exe
chown.exe
chroot.exe
cksum.exe
comm.exe
cp.exe
csplit.exe
cut.exe
date.exe
dd.exe
df.exe
dir.exe
dircolors.exe
dirname.exe
du.exe
echo.exe
env.exe
expand.exe
expr.exe
factor.exe
false.exe
fmt.exe
fold.exe
ginstall.exe
---
[
basename
cat
chgrp
chmod
chown
chroot
cksum
comm
cp
csplit
cut
date
dd
df
dir
dircolors
dirname
du
echo
env
expand
expr
factor
false
fmt
fold
ginstall
30,90c30,90
head.exe
hostid.exe
hostname.exe
id.exe
join.exe
kill.exe
link.exe
ln.exe
logname.exe
ls.exe
md5sum.exe
mkdir.exe
mkfifo.exe
mknod.exe
mv.exe
nice.exe
nl.exe
nohup.exe
Re: Test failures in coreutils-5.3.0 on cygwin
According to Jim Meyering on 1/11/2005 10:09 AM: Once I manually patched the corresponding Makefile.ins, I don't get very far into the testsuite (1 of 5 failed under tests/chgrp), see coreutils.check3. I haven't yet had time to figure out how to get any further. As for tests/chgrp/basic, further investigation shows that you are using `ls -c -t f g' to sort the listings of the two files. Did you intend to sort by ctime or by mtime? The failure is that cygwin is listing g as older than f. Unfortunately, the temp files are deleted as part of the test; I tried reproducing the steps of the test in my /tmp: $ touch f $ chown --from=:None -c :root f changed ownership of `f' to :root $ touch f g $ ~/coreutils-5.3.0/src/chgrp None f g $ ~/coreutils-5.3.0/src/chgrp root g $ sleep 1 $ ~/coreutils-5.3.0/src/chgrp None f $ ~/coreutils-5.3.0/src/chgrp '' f $ stat f g File: `f' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: d47c93feh/-730033154d Inode: 340645 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1007/ eblake) Gid: ( 513/None) Access: 2005-01-12 06:52:19.42150 -0700 Modify: 2005-01-12 06:52:19.42150 -0700 Change: 2005-01-12 06:51:35.95275 -0700 File: `g' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: d47c93feh/-730033154d Inode: 407455 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1007/ eblake) Gid: (0/root) Access: 2005-01-12 06:52:19.42150 -0700 Modify: 2005-01-12 06:52:19.42150 -0700 Change: 2005-01-12 06:52:19.42150 -0700 $ ls -t f g f g $ ls -c f g g f $ ls -c -t f g g f Is there a bug in the cygwin syscalls used by chgrp not changing the ctime like it should? You may want to consider moving the testsuite to an autotest framework from autoconf. That would help in pinpointing some of the bugs, and has better support for keeping all temp files around when a test fails. If you run `make -k check', it will keep going in spite of failures. Nope, even with `make -k check', my run ends in: == 1 of 5 tests failed Please report to bug-coreutils@gnu.org == make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp' make[2]: *** [check-am] Error 2 make[2]: Target `check' not remade because of errors. make[2]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp' make[1]: *** [check-recursive] Error 1 make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/home/eblake/coreutils-5.3.0/tests' make: *** [check-recursive] Error 1 make: Target `check' not remade because of errors. Thanks for the report and patch. I've made that change. Note that those patches don't apply because something (your mail client?) converted all TABs to spaces. User error -- I had copied and pasted from my terminal, rather than attaching, which flattened to spaces. One more patch is necessary to account for $(EXEEXT): since `groups' is a script and does not have $(EXEEXT), the .x.1 rule was breaking when it tried to build groups.1. Updating man page groups.1 groups.td/groups.exe: not found help2man: can't get `--help' info from groups.td/groups.exe make: *** [groups.1] Error 127 2005-01-12 Eric Blake [EMAIL PROTECTED] (tiny change) * man/Makefile.am (.x.1): Don't use $(EXEEXT). Also, I noticed that you have both coreutils-5.3.0/tests/tr/repeat-compl.I and coreutils-5.3.0/tests/tr/repeat-Compl.I in the tarball (and the problem still exists in CVS). This breaks in cygwin, which has case insensitive file names (only one of the two files gets unpacked), and is also a violation of the 8.3 file uniqueness naming rules required for porting to djgpp. Please consider renaming files to make coreutils DOS-friendly. -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] --- man/Makefile.am.orig2005-01-12 06:28:49.655875000 -0700 +++ man/Makefile.am 2005-01-12 06:29:13.030875000 -0700 @@ -128,10 +128,10 @@ @rm -f $@ @echo Updating man page $@; \ mkdir $t; \ - (cd $t $(LN_S) ../../src/$(mapped_name)$(EXEEXT) $*$(EXEEXT)); \ + (cd $t $(LN_S) ../../src/$(mapped_name) $*); \ $(PERL) -- $(srcdir)/help2man \ --include=$(srcdir)/$*.x\ - --output=$@ $t/$*$(EXEEXT) + --output=$@ $t/$* @chmod a-w $@ @rm -rf $t ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/12/2005 6:43 AM: autoreconf should work fine. Why are you using -f (--force)? Or -i (--install) for that matter? Using autoreconf (without -f) should work fine. Habit, I guess. You were correct that it worked without flags. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5TSE84KuGfSFAYARAswWAJwMN9nMT+hIN9K7dEaL1n+drAR9gwCfdEsA raupe6WayZk6sW79gI93o4Q= =Uu5s -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
make -k fails on cygwin [Was: Test failures in coreutils-5.3.0 on cygwin]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[cross-posted to cygwin and automake lists]
I'm not sure if the bug below is with cygwin's mods to make, in automake
for using non-portable Makefile constructs, or in both.
According to Jim Meyering on 1/12/2005 9:45 AM:
If you run `make -k check', it will keep going in spite of failures.
Nope, even with `make -k check', my run ends in:
==
1 of 5 tests failed
Please report to bug-coreutils@gnu.org
==
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp'
make[2]: *** [check-am] Error 2
make[2]: Target `check' not remade because of errors.
make[2]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp'
make[1]: *** [check-recursive] Error 1
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory `/home/eblake/coreutils-5.3.0/tests'
make: *** [check-recursive] Error 1
make: Target `check' not remade because of errors.
Then you should use a make program that honors the -k option.
There must be a GNU make port to cygwin.
It _is_ GNU make, but with cygwin modifications to accept --unix or
- --win32 to determine whether to use /bin/sh or the native DOS shell:
$ make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
$ cat Makefile
all:
@echo ${MAKEFLAGS}
$ make
- --unix
$ make -k
- --unix -k
Now look at what automake 1.9 sticks in to the Makefiles for recursive
traversal:
$(RECURSIVE_TARGETS):
@set fnord $$MAKEFLAGS; amf=$$2; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
echo Making $$target in $$subdir; \
if test $$subdir = .; then \
dot_seen=yes; \
local_target=$$target-am; \
else \
local_target=$$target; \
fi; \
(cd $$subdir $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case $$amf in *=*) exit 1;; *k*) fail=yes;; *) exit 1;;
esac; \
done; \
if test $$dot_seen = no; then \
$(MAKE) $(AM_MAKEFLAGS) $$target-am || exit 1; \
fi; test -z $$fail
Whoops - $amf is set to --unix, rather than the desired '' or -k. The
case statement fails, and the recursive traversal of subdirs halts in
spite of my request to keep going. As pointed out last month on the
libtool lists,
http://lists.gnu.org/archive/html/libtool-patches/2004-12/msg00091.html,
parsing $MAKEFLAGS is inherently non-portable. `info make' also has a
page dedicated to Phony Targets that discusses the more portable way to
have a recursive target, although I don't know how well it scales to the
more than 15 recursive targets that automake creates.
SUBDIRS = foo bar baz
.PHONY: subdirs $(SUBDIRS)
subdirs: $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@
foo: baz
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB50kf84KuGfSFAYARAmEdAKCTjFJlAWmPR9lDboMyGi8r2hiQNwCfaeQg
D/EyY+pF1kLs8c2LfOqD5O8=
=Elu+
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
more 5.3.0 issues on cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First, a ping on http://lists.gnu.org/archive/html/bug-coreutils/2005-01/msg00063.html, regarding non-portable group names (I have a cygwin box with the primary group name of Domain Users, which breaks the assumptions of tests/group-names that group names are space-separated). Next, another $(EXEEXT) bug was still floating around, this time in tests/Makefile.am, breaking the tests/help-version script. I think it would be easier to make the all_programs.list target of src/Makefile strip $(EXEEXT) rather than forcing all callers (currently man/Makefile and tests/Makefile) to do so, hence the attached patch. This also stops listing programs twice in the output, when they appear in both EXTRA_PROGRAMS and in OPTIONAL_BIN_PROGRAMS or DF_PROG. Finally, here are some trivial changes that have been part of the cygwin release. There are other changes in the cygwin install, but they are not trivial (for example, making cp, mv, and ln smart enough to auto-append .exe to the target if it was implied from the source name, since cygwin's stat() on `progname' is designed to work even if the file is really named `progname.exe'). 2005-01-17 Eric Blake [EMAIL PROTECTED] (tiny change) * src/Makefile.am (all_programs.list): Strip $(EXEEXT) and remove duplicates. * man/Makefile.am (all_programs): Revert previous patch; updated all_programs.list fixes this. (.x.1): No need to add $(EXEEXT). 2005-01-03 Corinna Vinschen [EMAIL PROTECTED] (tiny change) * src/install.c (strip): Check for .exe here since strip doesn't. * src/system.h: Use S_BLKSIZE value for ST_NBLOCKSIZE where available. * src/od.c (OPENMODE): New macro. (open_next_file): Use OPENMODE in fopen call. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB67nY84KuGfSFAYARAuL1AKCaEDY9WJC64Bs8zm6fYDK76yL+NACggo2D SCGG2xDjXdlK7+fNNSrqHBw= =mgTZ -END PGP SIGNATURE- Index: man/Makefile.am === RCS file: /cvsroot/coreutils/coreutils/man/Makefile.am,v retrieving revision 1.36 diff -u -p -r1.36 Makefile.am --- man/Makefile.am 11 Jan 2005 16:51:03 - 1.36 +++ man/Makefile.am 17 Jan 2005 13:09:06 - @@ -128,10 +128,10 @@ mapped_name = `echo $*|sed 's/install/gi @rm -f $@ @echo Updating man page $@; \ mkdir $t; \ - (cd $t $(LN_S) ../../src/$(mapped_name)$(EXEEXT) $*$(EXEEXT)); \ + (cd $t $(LN_S) ../../src/$(mapped_name) $*); \ $(PERL) -- $(srcdir)/help2man \ --include=$(srcdir)/$*.x\ - --output=$@ $t/$*$(EXEEXT) + --output=$@ $t/$* @chmod a-w $@ @rm -rf $t @@ -155,7 +155,7 @@ check-x-vs-1: all_programs = \ (cd ../src MAKEFLAGS= $(MAKE) -s all_programs.list) \ - | sed -e 's,$(EXEEXT)$$,,' | grep -v '\[' + | grep -v '\[' .PHONY: check-programs-vs-x check-programs-vs-x: Index: src/Makefile.am === RCS file: /cvsroot/coreutils/coreutils/src/Makefile.am,v retrieving revision 1.48 diff -u -p -r1.48 Makefile.am --- src/Makefile.am 11 Jan 2005 16:50:27 - 1.48 +++ src/Makefile.am 17 Jan 2005 13:09:06 - @@ -228,7 +228,8 @@ all_programs = \ $(EXTRA_PROGRAMS) all_programs.list: - @echo $(all_programs) | tr ' ' '\n' | $(ASSORT) + @echo $(all_programs) | tr ' ' '\n' | sed -e 's,$(EXEEXT)$$,,' \ + | $(ASSORT) -u pm = progs-makefile pr = progs-readme Index: src/system.h === RCS file: /cvsroot/coreutils/coreutils/src/system.h,v retrieving revision 1.98 diff -u -p -r1.98 system.h --- src/system.h3 Jan 2005 23:43:39 - 1.98 +++ src/system.h17 Jan 2005 13:09:06 - @@ -337,7 +337,11 @@ initialize_exit_failure (int status) #endif #ifndef ST_NBLOCKSIZE -# define ST_NBLOCKSIZE 512 +# ifdef S_BLKSIZE +# define ST_NBLOCKSIZE S_BLKSIZE +# else +# define ST_NBLOCKSIZE 512 +# endif #endif /* Redirection and wildcarding when done by the utility itself. Index: src/install.c === RCS file: /cvsroot/coreutils/coreutils/src/install.c,v retrieving revision 1.172 diff -u -p -r1.172 install.c --- src/install.c 26 Nov 2004 07:39:32 - 1.172 +++ src/install.c 17 Jan 2005 13:09:07 - @@ -566,6 +566,20 @@ strip (const char *path) error (EXIT_FAILURE, errno, _(fork system call failed)); break; case 0:/* Child. */ +#ifdef __CYGWIN__
bug in newlib strftime
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Newlib has several POSIX compliance issues in strftime(). See
http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html for
the mandated behavior. Since newlib does not support any locales other
than C, strftime() should be fixed to follow the mandated behavior. The
broken behavior of strftime() leads to failures in the coreutils program
date on cygwin and any other newlib-based platform.
Should coreutils add a configure-time check that looks for broken
strftime(), or should I just wait for a new version of newlib that fixes
the compliance issues?
In newlib, strftime() treats %r as , although Posix requires it to be
a synonym for %I:%M:%S %p in the POSIX/C locale. Likewise, newlib
treats %x as %a %b %d %Y, although Posix mandates %m/%d/%y.
Finally, newlib does not support the %E or %O modifiers, even though Posix
mandates that they be ignored for the conversion specifiers that support
them (in other words, %Ey, %Oy, and %y are all required and should
behave identically in the C locale, but since %Ea is not required, its
behavior is undefined). In the sample program below, the two output lines
should be identical.
$ cat foo.c
#include time.h
#include stdlib.h
#include locale.h
#define MAX_LEN 80
int main()
{
char str[MAX_LEN];
struct tm t;
setlocale(LC_ALL, C);
memset(t, 0, sizeof(t));
t.tm_sec = 30;
t.tm_min = 15;
t.tm_hour = 1; /* 1:15:30 AM */
t.tm_mday = 18; /* 18th */
t.tm_mon = 0; /* Jan */
t.tm_year = 105; /* 2005 */
t.tm_wday = 2; /* Tue */
strftime(str, MAX_LEN, %r#%x#%Ey#%Oy, t);
puts(str);
strftime(str, MAX_LEN, %I:%M:%S %p#%m/%d/%y#%y#%y, t);
puts(str);
return 0;
}
$ gcc -o foo foo.c
$ ./foo
#Tue Jan 18 2005#y#y
01:15:30 AM#01/18/05#05#05
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7mKr84KuGfSFAYARAjNdAKCjNw/IWf0ZxBMvHsAo6dm/T2gwogCfWjyK
4H/w5oTgp9MOZ/nZSTUYp5A=
=OA+F
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.3.0: cp --parents broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/25/2005 5:31 AM: * path-concat.c: Don't include assert.h. (path_concat): Remove assertion that would have triggered for ABASE starting with more than one slash. Reported by Andreas Schwab. Index: path-concat.c - concatenation. + concatenation. However, if ABASE begins with more than one slash, + set *BASE_IN_RESULT to point to the sole corresponding slash that + is copied into the result buffer. Collapsing //file/name to /file/name violates POSIX (some systems use that notation for remote machine shared drive access). XBD 3.2 defines absolute path as A pathname beginning with a single or more than two slashes, and XBD 4.11 agrees, so you are only allowed to collapse 3 or more leading slashes. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9kVV84KuGfSFAYARAji9AKDLesm9Z2W/GsUVDiLN3o8ByGmXBQCghxUe 58QaeshhPcay8SfXWqR2rls= =ygbP -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] bug in cygwin sys/termios.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 1/20/2005 9:36 PM: When compiling coreutils/src/stty.c, I got a warning: stty.c:106:1: warning: CSWTCH redefined In file included from /usr/include/termios.h:4, from stty.c:40: /usr/include/sys/termios.h:85:1: warning: this is the location of the previous definition After further googling, it looks like there are several systems which have VSWTC instead of VSWTCH, but still initialize mode-c_cc[VSWTC] with CSWTCH [1]. The following patch fixes this situation for coreutils. It also silences some annoyances from cvs updates. 2005-01-29 Eric Blake [EMAIL PROTECTED] (tiny change) * .cvsignore: Ignore config.cache and config.status.lineno. * src/stty.c [VSWTCH]: Some systems, like Cygwin, use VSWTC instead of VSWTCH, for use with CSWTCH. [1]http://mail.python.org/pipermail/python-checkins/2001-March/016197.html - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB/F/X84KuGfSFAYARApNlAJ9EMu0uuwcO+vtxNZcyoFI9wDz+RgCgwCwG vFqsu85FoQRXrmg4O/cVPcw= =kxhy -END PGP SIGNATURE- Index: .cvsignore === RCS file: /cvsroot/coreutils/coreutils/.cvsignore,v retrieving revision 1.5 diff -u -p -r1.5 .cvsignore --- .cvsignore 27 Sep 2004 07:23:23 - 1.5 +++ .cvsignore 30 Jan 2005 04:17:38 - @@ -2,7 +2,9 @@ Makefile THANKS-to-translators autom4te.cache +config.cache config.h config.log config.status +config.status.lineno stamp-h1 Index: src/stty.c === RCS file: /cvsroot/coreutils/coreutils/src/stty.c,v retrieving revision 1.129 diff -u -p -r1.129 stty.c --- src/stty.c 3 Nov 2004 23:17:29 - 1.129 +++ src/stty.c 30 Jan 2005 04:17:38 - @@ -1,5 +1,5 @@ /* stty -- change and print terminal line settings - Copyright (C) 1990-2004 Free Software Foundation, Inc. + Copyright (C) 1990-2005 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -100,10 +100,17 @@ #if defined(VEOL2) !defined(CEOL2) # define CEOL2 _POSIX_VDISABLE #endif +/* Some platforms have VSWTC, others VSWTCH. In both cases, this control + character is initialized by CSWTCH, if present. */ +#if defined(VSWTC) !defined(VSWTCH) +# define VSWTCH VSWTC +#endif /* ISC renamed swtch to susp for termios, but we'll accept either name. */ #if defined(VSUSP) !defined(VSWTCH) # define VSWTCH VSUSP -# define CSWTCH CSUSP +# if defined(CSUSP) !defined(CSWTCH) +# define CSWTCH CSUSP +# endif #endif #if defined(VSWTCH) !defined(CSWTCH) # define CSWTCH _POSIX_VDISABLE ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
some testsuite improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here are some minor fixes to the testsuites. New Makefile.am targets should be made phony for performance. When parsing file mode attributes, you need to consider that a file with ACLs set show up with an extra '+' at the end of the mode string. Also, group and user names can have shell metacharacters (such as space) in them. Cygwin creates new directories with ACLs set by default, so that files created in that directory have POSIX permissions rather than Windows permissions. This means that on cygwin, every new directory created during the testsuite has the ACL '+' flag, and that fact unnecessarily invalidated quite a few tests. $ mkdir dir $ getfacl dir # file: dir # owner: eblake # group: None user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x $ ls -ld dir drwxr-xr-x+ 2 eblake None 0 Jan 29 21:45 dir/ I have enough other patches in the works that you probably need to get me started on a copyright assignment offline. Is there any reason that all the Makefile.in and other generated files are stored in CVS? It is a bit annoying to have to filter them out of all my CVS diffs. 2005-01-29 Eric Blake [EMAIL PROTECTED] (tiny change) * tests/Makefile.am (.PHONY): Add check-root, check-recursive, and root-hint. * tests/rwx-to-mode: Ignore ACL designation. * tests/setgid-check: Likewise. * tests/chown/separator: Quote user and group names. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB/Ghq84KuGfSFAYARAu2oAJ9eqxzEaD8tejO0lsIXcd5gIdPL6ACfTkc1 HPejrySZhH7dJ2r1E2PxvYA= =BBmI -END PGP SIGNATURE- Index: tests/Makefile.am === RCS file: /cvsroot/coreutils/coreutils/tests/Makefile.am,v retrieving revision 1.18 diff -u -p -r1.18 Makefile.am --- tests/Makefile.am 4 Jan 2005 09:41:14 - 1.18 +++ tests/Makefile.am 30 Jan 2005 04:54:15 - @@ -24,6 +24,8 @@ SUBDIRS = \ rm rmdir seq sha1sum shred sort stty sum tac tail tail-2 test touch \ tr tsort unexpand uniq wc +.PHONY: check-root check-recursive evar-check root-hint + check-root: cd chown $(MAKE) check TESTS=basic cd cp $(MAKE) check TESTS=special-bits @@ -33,7 +35,6 @@ check-root: check-recursive: evar-check root-hint # Warn when `make check' is run with POSIXLY_CORRECT or CDPATH set. -.PHONY: evar-check evar-check: ../src/printenv POSIXLY_CORRECT /dev/null \ sed s/%%/POSIXLY_CORRECT/ $(srcdir)/.env-warn || : Index: tests/rwx-to-mode === RCS file: /cvsroot/coreutils/coreutils/tests/rwx-to-mode,v retrieving revision 1.5 diff -u -p -r1.5 rwx-to-mode --- tests/rwx-to-mode 7 Nov 2000 14:20:06 - 1.5 +++ tests/rwx-to-mode 30 Jan 2005 04:54:15 - @@ -1,7 +1,7 @@ #!/bin/sh # Convert an ls-style permission string, like drwxrx and -rw-r-x-wx # to the equivalent chmod --mode (-m) argument, (=,u=rwx,g=r,o=x and -# =,u=rw,g=rx,o=wx). +# =,u=rw,g=rx,o=wx). Ignore ACLs. case $# in 1) rwx=$1;; @@ -12,6 +12,7 @@ esac case $rwx in [ld-][rwx-][rwx-][rwxsS-][rwx-][rwx-][rwxsS-][rwx-][rwx-][rwxtT-]) ;; + [ld-][rwx-][rwx-][rwxsS-][rwx-][rwx-][rwxsS-][rwx-][rwx-][rwxtT-]+) ;; *) echo $0: invalid mode string: $rwx 12; exit 1;; esac Index: tests/setgid-check === RCS file: /cvsroot/coreutils/coreutils/tests/setgid-check,v retrieving revision 1.3 diff -u -p -r1.3 setgid-check --- tests/setgid-check 23 Jun 2004 15:07:00 - 1.3 +++ tests/setgid-check 30 Jan 2005 04:54:15 - @@ -13,6 +13,7 @@ p=`ls -ld $setgid_tmpdir|sed 's/ .*//'` rmdir $setgid_tmpdir case $p in drwx--);; + drwx--+);; drwxr-xr-x);; # Windows98 + DJGPP 2.03 + fileutils-4.1 does this. *) cwd_is_setgid=yes;; esac Index: tests/chown/separator === RCS file: /cvsroot/coreutils/coreutils/tests/chown/separator,v retrieving revision 1.2 diff -u -p -r1.2 separator --- tests/chown/separator 14 Jan 2005 10:39:05 - 1.2 +++ tests/chown/separator 30 Jan 2005 04:54:15 - @@ -37,8 +37,8 @@ fail=0 chown '' . || fail=1 -for u in $id_u $id_un ''; do - for g in $id_g $id_gn ''; do +for u in $id_u $id_un ''; do + for g in $id_g $id_gn ''; do case $u$g in *.*) seps=':' ;; *) seps=': .' ;; ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to James Youngman on 2/1/2005 3:17 AM: Unix systems automatically generate sparse files when programs seek forwards on their output file. There is no need to have a sparse attribute. This is what coreutils' cp does. Windows and NTFS don't work in this way. Under NTFS, there is, as you say, a sparse attribute which must be set. GNU coreutils runs on Windows under Cygwin and am not sure if Cygwin exposes any form of API which might allow cp to set the sparse attribute. It's certainly a lot more complex to do this under Windows. According to the cygwin mailing list, http://sources.redhat.com/ml/cygwin/2005-02/msg00013.html, cygwin already supports sparse files when you do lseek beyond EOF during writes. The trick, however, is that NTFS on Windows XP does not create a hole until 128k. Therefore, this patch is needed in the testsuite to turn a SKIP into a PASS on cygwin: 2005-02-01 Eric Blake [EMAIL PROTECTED] (tiny change) * tests/du/8gb: Detect sparse files on NTFS under cygwin. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAEZA84KuGfSFAYARAiFSAKDF7lb6zJq6ADLsFyHPrgkQ30tDaACcDT7P 8lGA+YY7czPjlGfVQYRANaQ= =E+76 -END PGP SIGNATURE- Index: tests/du/8gb === RCS file: /cvsroot/coreutils/coreutils/tests/du/8gb,v retrieving revision 1.6 diff -u -p -r1.6 8gb --- tests/du/8gb3 May 2003 14:24:37 - 1.6 +++ tests/du/8gb2 Feb 2005 03:19:31 - @@ -26,7 +26,8 @@ fi # If this file system doesn't support sparse files, # don't try to create a file that'd end up consuming 8GB. # This happens on Darwin6.5 with a file system of type `hfs'. -dd bs=1 seek=64K of=t /dev/null 2 /dev/null +# NTFS requires 128K before a hole appears in a sparse file. +dd bs=1 seek=128K of=t /dev/null 2 /dev/null set x `du -sk t` if test $2 = 64; then echo $0: skipping this test, since this file system doesn't support 12 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: AW: cp command - problem with sparse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to RE on 2/2/2005 3:11 AM: Hi Eric, Maybe you can answer my question or help me with my sparse problem which I am quoting in the following once again. [BTW I don't know if the patch you sent me will be needed, but if yes, I would not know how to apply it ;-((( ] You never stated which platform you are using; the output of `cp - --version' and `uname -a' would be useful in your bug report. Are you using cygwin or mingw, or are you accessing the NTFS drive remotely from a *nix box? If your problem is with the cygwin port of cp, then the cygwin AT cygwin DOT com mailing list is the correct place to ask; I see you've repeated your question there, so I will let that thread answer your question. The patch I sent was for the coreutils test suite, and has no bearing on the actual cp command. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCANNv84KuGfSFAYARAr6KAJ44haWj8ZHnfPNblc6vN/mgHBy59gCeMczA s6HhkIBfpgMOM8/EqN9Dtzk= =Q9sc -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to James Youngman on 2/1/2005 3:17 AM: Unix systems automatically generate sparse files when programs seek forwards on their output file. There is no need to have a sparse attribute. This is what coreutils' cp does. Right now, the tests/du/8gb test uses dd to try to create a sparse file; and strace'ing that on cygwin shows that it uses just lseek() followed by ftruncate() (no intervening write()). But the code in src/copy.c goes to great lengths to write() before calling ftruncate(), with the comment that the kernel would truncate the file at the end of the last write operation. Which is it? Is copy doing more work than it should, or should dd also be doing a write before truncate? POSIX does say that ftruncate shall increase the size of the file in XSI systems, but allows it return an error and keep the size unchanged on non-XSI systems. I ask, because at the moment, cygwin's implementation only makes a sparse file on write() after lseek(), although the developers are considering making ftruncate() after lseek() also create a sparse file. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAaOB84KuGfSFAYARAoXxAJ9nbKLwI8fGcdAJ9vVggGwehujbFwCgnIuv kmBzebHsRNu4iHb7q1vPGE0= =Wpzz -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: random errors from rm
Bob Proulx bob at proulx.com writes: Gee M Wong wrote: I updated to the setup 2.457.2.2 from 2.427 and started getting random errors from rm. What do the numbers 2.457.2.2 from 2.427 mean in this context? I can't place them. They don't seem to be related to GNU coreutils. That sounds suspiciously like the version numbers of the setup.exe program used to install cygwin, but they have no bearing on your installed version of either cygwin or coreutils, so I cannot offer more help without more information. I do suggest, however, that you take cygwin specific questions to cygwin AT cygwin DOT com, not here. It seems strange to me that your user name and group names are capitalized strings Gee and None. You have a group None? Strange but probably okay. None is a standard group name on Windows NT, typically found on home installations that have no need for fancier group memberships. Gee at gee ~ $ rm aaa rm: cannot remove `aaa': No such file or directory I can't reproduce that on cygwin, either on Win9x or on WinXP, so I have no clue where your problem is coming from. That does seem strange. You created the file so it should be in your default group. Now you should be able to remove the file. However I wonder about a few things. What is the output of these commands? id ls -ld ls -ldn . aaa I would also see if other commands also have errors. perl -e 'unlink( at ARGV) or die at ARGV: $!\n' aaa But other than these things I can't imagine what would create the behavior you are seeing. Bob -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv and hard links
This may be worthy of raising an issue with the austin group, but I thought I'd ask here first. A complaint was raised on the cygwin list that the following sequence had no interactive prompt: $ uname CYGWIN_NT-5.0 $ touch a $ ln a b $ mv -i a b $ echo $? 0 $ mv --version | head -n 1 mv (GNU coreutils) 5.3.0 Further checking shows that other implementations have different behavior, and that the coreutils behavior is platform-independent: $ uname -a SunOS perth 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Blade-100 Solaris $ touch a $ ln a b $ /usr/xpg4/bin/mv -i a b mv: a and b are identical $ echo $? 2 $ mv --version | head -n 1 mv (GNU coreutils) 5.3.0 $ mv -i a b $ echo $? 0 By my reading of POSIX, http://www.opengroup.org/onlinepubs/009695399/utilities/mv.html, neither implementation is compliant. Step 1 requires that since b exists, -f is not in force, and -i is in force, that a prompt be issued before anything further is attempted. Neither Solaris nor coreutils did this, and I can't think of a reason to justify their non-compliance. Then, in step 2 (whether -i is omitted or the (missing) prompt of step 1 was answered affirmitively), POSIX requires that mv defer to rename(), and that if rename() suceeds that no further steps are taken. rename() requires that If the old argument and the new argument resolve to the same existing file, rename() shall return successfully and perform no other action. Therefore, the POSIX behavior is that `mv a b' leave both a and b intact, and exit with status 0. The Solaris behavior of printing a diagnostic and exiting non-zero is justifiable because users do not expect for mv to leave the source intact when it was successful. And the coreutils behavior seems reasonable, especially since coreutils/src/copy.c documents that POSIX mistakenly requires that such a rename call do *nothing* and return successfully, because by using the workaround of calling unlink() on the source when the two files are the same, `mv a b' has the same net behavior whether a and b are hard links or not. The trick now is deciding what wording should be used to permit the desired behaviors, or deciding that coreutils behavior needs to be changed to become compliant. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
binary mode copies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following patch, first proposed for cygwin, is needed on systems like cygwin where not copying in binary mode can lead to data corruption. This affects mv, cp, and install. 2005-03-15 Corinna Vinschen [EMAIL PROTECTED] (tiny change) * src/copy.c (copy_reg): Copy regular files in binary mode. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCNugZ84KuGfSFAYARAgF8AKC/qf+RiEbdtA2OcjFQe+Ub/8x9LQCgoPPi 0Rp+rSy0gzljm0XBW2B9VsQ= =k8IZ -END PGP SIGNATURE- --- src/copy.c 11 Mar 2005 09:36:52 - 1.176 +++ src/copy.c 15 Mar 2005 13:36:56 - @@ -273,6 +273,7 @@ return_val = false; goto close_src_desc; } + SET_BINARY2 (source_desc, dest_desc); /* Determine the optimal buffer size. */ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: binary mode copies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 3/15/2005 3:47 PM: 2005-03-15 Corinna Vinschen [EMAIL PROTECTED] (tiny change) * src/copy.c (copy_reg): Copy regular files in binary mode. By the way, can you produce a small test case that fails without this patch and that succeeds with it? Best would be a patch adding a test to be run by `make check'. I'll see what I can come up with. It only fails on cygwin when directories are mounted as text mode, rather than binary mode; but to date I've always run the testsuite on a binary mode mount. I'll have to run the tests from a text mount point, and see what other problems it uncovers. A test should be a simple as verifying file sizes after copying two files, one with \n and the other with \r\n line endings. My biggest obstacle now is that I still don't have my employer's signature permitting me to contribute to FSF. Otherwise, I already have several other testsuite improvements lined up for contribution. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCN5Fx84KuGfSFAYARAvE0AJoDxeKTwIHJmPMiHtqrj6frc0iwggCgmCGk D+On4fWqCilvgTJbXVA3Rfg= =bfft -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp -lL' behaviour conflicts with documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 3/15/2005 10:35 AM: But the actual referent (as opposed to the symlink value) may be another symlink, which may point to another, etc. The final non-symlink value -- assuming there is one -- is the referent. It'd be easy if there were an flink syscall. Then you'd just open the symlink (which would open the referent) and use flink to create a hard link to the file behind the descriptor. Is it worth it to make cp manually follow a sequence of symlinks when given both -L and --link? On a related matter, POSIX is a bit ambiguous about link utilities when the source is a (nested) symlink. For link(1), it defers strictly to link(2), which does not directly mention what to do if path1 is a symlink. And for ln(1), step 3 states that link(2) should be called using the object that source_file references as the path1 argument, without saying whether this must be the final referrent (or an error for broken links or loops) or just a single dereference that might be another symlink. Personally, I think that ln(1) should by default always try to resolve the symlink down to a non-symlink file, and error out if that is not possible; and that link(1) should be used to make hard links to symlinks on architectures whose link(2) permit that. Maybe it is also worth adding -H - -L and -P to ln to bypass my proposed default, at the same time as fixing cp -lL. At any rate, the following sequence is a bug in ln(1), because it does not involve any of the above-mentioned ambiguities: $ uname CYGWIN_NT-5.1 $ touch a $ ln -s a b $ ln b c # Bug: c should be a hard link to a, not b $ ls -l a b c - -rw-r--r-- 1 eblake None 0 Mar 15 19:04 a lrwxrwxrwx 2 eblake None 1 Mar 15 19:04 b - a lrwxrwxrwx 2 eblake None 1 Mar 15 19:04 c - a - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCN5Zp84KuGfSFAYARAvauAJ9LNWYcbYUdTRM5R2gyl/O9aB0PXwCfV3JJ OwbX0fTnpnDNolsx8R0bPA8= =X51t -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp -lL' behaviour conflicts with documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 3/16/2005 1:53 AM: $ touch a $ ln -s a b $ ln b c # Bug: c should be a hard link to a, not b $ ls -l a b c -rw-r--r-- 1 eblake None 0 Mar 15 19:04 a lrwxrwxrwx 2 eblake None 1 Mar 15 19:04 b - a lrwxrwxrwx 2 eblake None 1 Mar 15 19:04 c - a It does seem to be a messy area. It's not clear to me that POSIX was intended to specify what it does. Personally I prefer the GNU ln behavior, on hosts that support hard links to symlinks: it's much cleaner and easier to explain. One more point to consider. With GNU behavior, the next command of `rm a' leaves both `b' and `c' as dangling pointers, and loses the file; while with POSIX behavior, `rm a' leaves `b' dangling, but `c' still contains the contents of `a' so no data has been lost (provided you know its alternate name). It comes down to a question of whether creating the hard link named c should preserve the metadata (b is a symlink to a) or the data (the contents of a), when someone is using hard links to avoid data loss. Both behaviors seem reasonable, so it is probably worth a command-line option in ln. Maybe this should be brought before the POSIX committee? I agree, and just posted the issue to the austin group. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCODqn84KuGfSFAYARAmw3AKDQ/RUwsJHr0JbWTLbwMYln7IsRRQCgxfS5 Je7Wcyqot1gBGAiQWqLrCoM= =wV/t -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: color support for TERM=cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 3/26/2005 12:16 AM: Thanks; I installed the obvious change to src/dircolors.hin. Any reason the terminal names aren't sorted in any particular order? I'm not so sure. Such users are not casual, and they can look at the source. In fact, I had rather the reverse in mind: dircolors and dcgen could be simplified as shown below. I'm okay with leaving `dircolors -p' with no comments, but it is a user-visible change from 5.2.1 that probably should have been mentioned in the NEWS for 5.3.0 (revision 1.3 of dcgen was checked in during July 04). This fact adds all the more impetus to improving the info pages to describe the dircolors input file format, as well as the LS_COLORS format, rather than referring to a dircolors invocation that no longer carries helpful hints. I also think that it is okay for `dircolors --help' to point to the info pages rather than trying to repeat the input file format inline (right now it is still pointing to `dircolors -p'). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSGeu84KuGfSFAYARAp/bAJ4jk7kAkRY1zge5jn3mZR1SOond9wCgusj6 u+HDk/k1YGFMVWMkZ7Pz1pQ= =Brcz -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Probem with join and accentuated characters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Boris New on 3/31/2005 1:54 PM: Hi, I send you the zip file with the two files. I tested a lot of windows port and all have this problem. I thought it was perhaps due to locale on windows. The format is the same and files are sorted. Everything is ok if I remove accentuated words from rand.txt. Contrary to your assertion, your files were not sorted. Or put another way, they weren't sorted by the same rules that join expected. There are some locales that treat é and e as the same collating character, but the C locale that is the default of cygwin is not one of them. Hence, join gave up after the first line where the sorting failed to match its expectations. Run the following to show this: $ sort rand.txt randsort.txt $ diff rand.txt randsort.txt Only if the diff turns up no change on both files will join work like you want, for the locale you are using. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTL1D84KuGfSFAYARAud5AJ0ZzqemqItQ3oTcMiYqz08dtojsyQCeNe/O n5V+udbdLBKFEbW/Qg8pOGU= =pvms -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI: --help now warns about built-in conflicts
FYI, Before, 3 man pages (echo, printf, pwd) included a warning like this: NOTE: your shell may have its own version of printf, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. I've put that warning in the --help output of 7 commands (actually, it's 8.5 if you count `[' and `false'), so it will now appear automatically in the generated man/*.1 files. If anyone knows of any other coreutils commands that are built-in, please let me know. tcsh provides nice, nohup, and printenv. Not that csh-variants are POSIX-compliant, but they are often a user's default shell, so these three should also get the warning. Initially, I added those three lines at the very top (between the Usage line(s) and the short description), since mistaking the man-page as a reference for the built-in is such a common problem. But I didn't like that. Now it's at the end, e.g.: Is there any way to get the --help output to put the warning at the end, but the man page to list it at the front? With --help, the last thing printed is most important, but in man pages, the first screenful is most important. What does help2man offer to help us acheive this? Do we need a new section name? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug, i think? pwd --help and pwd --version don't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Philip Rowlands on 4/8/2005 2:14 AM: built-in pwd implementations can be confusing as they will in some circumstances return a different directory to /bin/pwd, if you have cd'd through a symlink. e.g. $ mkdir a ln -s a b $ cd b $ pwd /tmp/b $ /bin/pwd /tmp/a Actually, POSIX requires the behavior you've documented here for the shell's builtin, as I reported here: http://lists.gnu.org/archive/html/bug-coreutils/2005-02/msg00085.html. pwd(1) is by default supposed to print logical paths (by reading $PWD), and only if that fails or -P was specified, print the physical path. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVobl84KuGfSFAYARAvHEAJ94iM/TWObFYxOklqliiyDP7KT7kACgsdke W8mmsUzyOk8hKgsMfArV010= =ppwl -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug, i think? pwd --help and pwd --version don't work
[EMAIL PROTECTED] ~]$ pwd --help
bash: pwd: --: invalid option
pwd: usage: pwd [-PL]
[EMAIL PROTECTED] ~]$ which pwd
/usr/local/bin/pwd
Strange. Any idea what's going wrong?
Yes - which(1) is not required by POSIX, but it is a tcsh builtin that
corresponds to the POSIX-required type(1). Depending on whether type/which is
a program, an alias, or a shell-builtin, it reports different information -
only a shell builtin can report correct information about shell builtins and
aliases. In conclusion, your information about what pwd really is depends on
how you ask. On my system:
$ bash# where pwd is builtin, type is builtin, which is program
$ type pwd
pwd is a shell builtin
$ which pwd
/usr/bin/pwd
$ type which
which is hashed (/usr/bin/which)
$ which which
/usr/bin/which
$ type type
type is a shell builtin
$ which type
type: Command not found.
$ tcsh # where pwd is program, type is alias for which, which is builtin
# type pwd
/usr/bin/pwd
# \type pwd
type: Command not found.
# which pwd
/usr/bin/pwd
# type which
which: shell built-in command.
# which type
type:aliased to which
#
If you want the tcsh behavior of which inside of bash, then do something like
one of these two options:
$ alias which type
$ which()
{
type $@
}
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
dos filename portability in pathchk
Wishlist items (I know - it probably won't get implemented if I don't assign copyright and submit the patch myself...) It would be nice if pathchk supported -d (--dos) that warned about filenames that are not portable to Windows based systems, such as cygwin. I don't know whether --portability should imply -d or not. For example, $ pathchk --port aux.sh foo. ; echo $? 0 $ pathchk -d aux.sh foo. ; echo $? pathchk: stem `aux' in filename `aux.sh' is nonportable to DOS pathchk: trailing `.' in filename `foo.' is nonportable to DOS 1 And a possibility for one other option is case-sensitivity, -c. It could warn between conflicts of multiple arguments, or between the spelling given to pathchk vs. the spelling on disk. This is useful for FAT, NTFS, HFS+, and other case-preserving case-insensitive file systems. $ touch foo $ pathchk -c FOO pathchk: case conflict between filename `FOO' and existing file `foo' $ pathchk -c bar BAR pathchk: case conflict between filename pair `bar' and `BAR' Because of command line length limitations, `find . -print | xargs pathchk -c' might not find all case conflicts, so it would be nice if pathchk could operate as a filter when no filenames are supplied, allowing `find . -print | pathchk -c'. Which also implies that `find . -print0 | pathchk -0 -c' should work... -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mknod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Costa on 4/14/2005 8:07 AM: Hi Everybody, I have a problem on cygwin: You should ask this question on the cygwin mailing list, [EMAIL PROTECTED] mknod pipe p POSIX states that named pipes (aka fifos) are only portable if used in one direction (ie. you can't open them read-write and expect portable results). Beyond that, named pipes are a relatively new addition to cygwin, and there are still bugs being ironed out. For example, $ mkfifo f # shorthand for mknod f p $ ls -iF f 1125899907358221 f| $ mv f f1 $ ls -iF f1 1125899907358221 f1 preserves the inode, but changes the file type from pipe to a regular file (read-only at that). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXwZS84KuGfSFAYARAl30AKCir40E0f1Y5SySvAmXN6GNk62dMgCg1kN7 b4tS9djYzJ84Z0z6j+oZWvM= =2Kee -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cygwin failing tests/mv/mv-special-1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/14/2005 2:37 PM:
Thanks for that bug report. I installed this patch: does it fix both
your problems?
Almost - there are some further cleanups that can be made. First, we
might as well dereference symlinks (one of the CANDIDATE_TMP_DIRS could be
a cross-device symlink instead of a mount point). Second, this is
coreutils, so we have a reliable test(1) - the comment about `test -e' not
being portable is irrelavant. Third, mv-special-1 is not being careful
that the named pipe is still a named pipe on the destination.
2005-04-15 Eric Blake [EMAIL PROTECTED] (tiny change)
* tests/mv/mv-special-1: Use our own test(1) to check that
hierarchy was correctly moved.
* tests/mv/setup (dot_mount_point): Dereference symlinks when
learning device number.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCX7lV84KuGfSFAYARAgJoAJ9PRrTye40nmA1oVBMLutYkrYfh7QCeJ3tb
OBGpeaxOxrfwwwOqcFeEodc=
=j0Mw
-END PGP SIGNATURE-
Index: tests/mv/mv-special-1
===
RCS file: /cvsroot/coreutils/coreutils/tests/mv/mv-special-1,v
retrieving revision 1.24
diff -u -p -r1.24 mv-special-1
--- tests/mv/mv-special-1 14 Apr 2005 20:35:14 - 1.24
+++ tests/mv/mv-special-1 15 Apr 2005 12:51:52 -
@@ -43,11 +43,11 @@ fi
fail=0
mv --verbose $null $dir $other_partition_tmpdir out || fail=1
# Make sure the files are gone.
-test -f $null fail=1
+# shell builtin test -e is not portable, so use our own
+${BUILD_SRC_DIR?}/test -e $null fail=1
test -d $dir fail=1
# Make sure they were moved.
-# Since `test -e' is not portable, use `ls'.
-ls $other_partition_tmpdir/$null /dev/null || fail=1
+$BUILD_SRC_DIR/test -p $other_partition_tmpdir/$null || fail=1
test -d $other_partition_tmpdir/$dir/a/b/c || fail=1
# POSIX says rename (A, B) can succeed if A and B are on different file
systems,
Index: tests/mv/setup
===
RCS file: /cvsroot/coreutils/coreutils/tests/mv/setup,v
retrieving revision 1.13
diff -u -p -r1.13 setup
--- tests/mv/setup 14 Apr 2005 20:35:34 - 1.13
+++ tests/mv/setup 15 Apr 2005 12:51:52 -
@@ -9,13 +9,13 @@ test ${CANDIDATE_TMP_DIRS+set} = set \
other_partition_tmpdir=
-dot_mount_point=`stat -c %d .`
+dot_mount_point=`stat -Lc %d .`
for d in $CANDIDATE_TMP_DIRS; do
# Skip nonexistent directories.
test -d $d || continue
- d_mount_point=`stat -c %d $d`
+ d_mount_point=`stat -Lc %d $d`
# Same partition? Skip it.
test x$d_mount_point = x$dot_mount_point continue
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
testsuite portability nit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On cygwin, where /bin/sh is ash, trap '' CHLD doesn't work (ash only
accepts signal numbers, not names):
$ trap '' CHLD
trap: bad signal CHLD
But CHLD is not one of the portable signal numbers (it is 20 on cygwin,
but other numbers on other platforms). Not all versions of kill(1) can
convert names to numbers, but this is coreutils.
Furthermore, install needs to use $EXEEXT on arguments.
2005-04-16 Eric Blake [EMAIL PROTECTED]
* tests/install/Makefile.am (TESTS_ENVIRONMENT): Propagate
BUILD_SRC_DIR and EXEEXT to tests.
* tests/install/basic-1: Use EXEEXT.
* tests/install/trap: trap '' CHLD is not portable on
Cygwin. Also, use EXEEXT.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCYZM784KuGfSFAYARAvu1AJ4u2qNQIlvTiVMz3OYnS/QeomZhYACfUoWe
DyToYY44Z2r+NZeKCoXNUr4=
=/O1E
-END PGP SIGNATURE-
Index: tests/install/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/tests/install/Makefile.am,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile.am
--- tests/install/Makefile.am 10 May 2004 15:13:45 - 1.7
+++ tests/install/Makefile.am 16 Apr 2005 22:33:13 -
@@ -4,4 +4,6 @@ AUTOMAKE_OPTIONS = 1.3 gnits
TESTS = trap basic-1 create-leading
EXTRA_DIST = $(TESTS)
TESTS_ENVIRONMENT = \
- PATH=`pwd`/../../src$(PATH_SEPARATOR)$$PATH
+ PATH=`pwd`/../../src$(PATH_SEPARATOR)$$PATH \
+ EXEEXT=$(EXEEXT) \
+ BUILD_SRC_DIR=`pwd`/../../src
Index: tests/install/Makefile.in
===
RCS file: /cvsroot/coreutils/coreutils/tests/install/Makefile.in,v
retrieving revision 1.139
diff -u -p -r1.139 Makefile.in
Index: tests/install/basic-1
===
RCS file: /cvsroot/coreutils/coreutils/tests/install/basic-1,v
retrieving revision 1.11
diff -u -p -r1.11 basic-1
--- tests/install/basic-1 11 Aug 2004 23:41:59 - 1.11
+++ tests/install/basic-1 16 Apr 2005 22:33:13 -
@@ -34,10 +34,10 @@ test -f $file || fail=1
test -f $dir/$file || fail=1
# Make sure strip works.
-cp ../../../src/dd .
-cp dd dd2
+cp ../../../src/dd${EXEEXT} .
+cp dd${EXEEXT} dd2${EXEEXT}
-strip dd2 || \
+strip dd2${EXEEXT} || \
{
cat 12 EOF
$0: WARNING!!!
@@ -49,12 +49,12 @@ EOF
# This test would fail with 3.16s when using versions of strip that
# don't work on read-only files (the one from binutils works fine).
-ginstall -s -c -m 555 dd $dir || fail=1
+ginstall -s -c -m 555 dd${EXEEXT} $dir || fail=1
# Make sure the source file is still around.
-test -f dd || fail=1
+test -f dd${EXEEXT} || fail=1
# Make sure that the destination file has the requested permissions.
-set X `ls -l $dir/dd`
+set X `ls -l $dir/dd${EXEEXT}`
shift
test $1 = -r-xr-xr-x || fail=1
Index: tests/install/trap
===
RCS file: /cvsroot/coreutils/coreutils/tests/install/trap,v
retrieving revision 1.1
diff -u -p -r1.1 trap
--- tests/install/trap 10 May 2004 15:13:29 - 1.1
+++ tests/install/trap 16 Apr 2005 22:33:13 -
@@ -24,7 +24,8 @@ fi
fail=0
# Before 2004-04-21, install would infloop, in the `while (wait...' loop:
-trap '' CHLD
-ginstall -s $pwd/../../src/ginstall .
+# neither trap '' CHLD nor trap '' `kill -l CHLD` is portable
+trap '' `${BUILD_SRC_DIR?}/kill -l CHLD`
+ginstall -s $pwd/../../src/ginstall${EXEEXT} .
(exit $fail); exit $fail
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: testsuite portability nit
On cygwin, where /bin/sh is ash, trap '' CHLD doesn't work (ash only accepts signal numbers, not names): $ trap '' CHLD trap: bad signal CHLD But CHLD is not one of the portable signal numbers (it is 20 on cygwin, but other numbers on other platforms). Not all versions of kill(1) can convert names to numbers, but this is coreutils. The names should be used instead of numbers. That is, the existing usage seems to be the right thing to do; it's what POSIX mangates nowadays. See http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html. I'm in total agreement that POSIX requires support for names, but my argument was that cygwin's /bin/sh (and any other platform that uses ash or other non-POSIX shells for /bin/sh) does not support names. Look at the screenshot you quoted from my original mail. Hence, my proposed patch is the only 'portable' way I could come up with to supply the number to trap; and even that is not portable outside of the coreutils testsuite, because it relies on coreutils kill(1) to do the translation from name to number. See my query to the autoconf list a while back: http://lists.gnu.org/archive/html/autoconf/2005-01/msg00136.html -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: testsuite portability nit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 4/18/2005 12:39 AM: I installed the following patch, in the hopes that it'd be relatively simple and easy to maintain. It skip the tests on the platforms with the contrary-to-POSIX glitches. 2005-04-17 Paul Eggert [EMAIL PROTECTED] Work around a couple of make check failures reported for Cygwin and ash by Eric Blake. * tests/install/basic-1: Skip this test if ../../src/dd isn't readable. * tests/install/trap: Skip this test if trap '' CHLD doesn't work. What was wrong with my proposed patch? It made both of these tests PASS instead of SKIP on cygwin, always a good goal in testsuite coverage. And my patch to tests/install/trap was shorter than your patch to skip it, so I argue that it was simple and easy enough to maintain. Furthermore, your patch to tests/install/basic-1 does not solve the problem: `test -r ../../src/dd' succeeds on cygwin because of .exe magic built in to cygwin stat(2); the failure comes later when open(2) fails after the stat(2) succeeded because the filename is missing the extension (in cp(1) if I have not applied my cygwin .exe patches to cp yet, otherwise in strip(1) called by ginstall). Propagating $EXEEXT to the testsuite completely works around half-baked .exe magic in cygwin by explicitly specifying it up front instead of relying on cygwin magic to determine when it is needed. Under your patch: $ make -C tests/install check TESTS=basic-1 VERBOSE=yes make: Entering directory `/home/eblake/coreutils/tests/install' make check-TESTS make[1]: Entering directory `/home/eblake/coreutils/tests/install' + ginstall --version install (GNU coreutils) 5.3.1 Written by David MacKenzie. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + dir=dir + file=file + test -r ../../src/dd + pwd + pwd=/home/eblake/coreutils/tests/install + tmp=inst-basic.3840 + trap status=$?; cd $pwd; rm -rf $tmp exit $status 0 + trap exit $? 1 2 13 15 + framework_failure=0 + mkdir inst-basic.3840 + cd inst-basic.3840 + rm -rf dir file + mkdir -p dir + echo foo + test 0 = 1 + fail=0 + ginstall file dir + test -f file + test -f dir/file + cp ../../../src/dd . cp: cannot open `../../../src/dd' for reading: No such file or directory + cp dd dd2 cp: cannot stat `dd': No such file or directory + strip dd2 strip: 'dd2': No such file + ginstall -s -c -m 555 dd dir ginstall: cannot stat `dd': No such file or directory + fail=1 + test -f dd + fail=1 + ls -l dir/dd ls: dir/dd: No such file or directory + set X + shift + test = -r-xr-xr-x + fail=1 + ginstall -d . + ginstall -d newdir + ginstall -d newdir1 newdir2 newdir3 + exit 1 + exit 1 + status=1 + cd /home/eblake/coreutils/tests/install + rm -rf inst-basic.3840 + exit 1 FAIL: basic-1 == 1 of 1 tests failed Please report to bug-coreutils@gnu.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/eblake/coreutils/tests/install' make: *** [check-am] Error 2 make: Leaving directory `/home/eblake/coreutils/tests/install' Under my patch: $ make -C tests/install check TESTS=basic-1 VERBOSE=yes make: Entering directory `/home/eblake/coreutils/tests/install' make check-TESTS make[1]: Entering directory `/home/eblake/coreutils/tests/install' + ginstall --version install (GNU coreutils) 5.3.1 Written by David MacKenzie. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + dir=dir + file=file + test -r ../../src/dd + pwd + pwd=/home/eblake/coreutils/tests/install + tmp=inst-basic.2796 + trap status=$?; cd $pwd; rm -rf $tmp exit $status 0 + trap exit $? 1 2 13 15 + framework_failure=0 + mkdir inst-basic.2796 + cd inst-basic.2796 + rm -rf dir file + mkdir -p dir + echo foo + test 0 = 1 + fail=0 + ginstall file dir + test -f file + test -f dir/file + cp ../../../src/dd.exe . + cp dd.exe dd2.exe + strip dd2.exe + ginstall -s -c -m 555 dd.exe dir + test -f dd.exe + ls -l dir/dd.exe + set X -r-xr-xr-x 1 eblake None 39424 Apr 18 06:55 dir/dd.exe + shift + test -r-xr-xr-x = -r-xr-xr-x + ginstall -d . + ginstall -d newdir + ginstall -d newdir1 newdir2 newdir3 + exit 0 + exit 0 + status=0 + cd /home/eblake/coreutils/tests/install + rm -rf inst-basic.2796 + exit 0 PASS: basic-1 == All 1 tests passed == make[1]: Leaving directory `/home/eblake/coreutils/tests/install' make: Leaving directory `/home/eblake/coreutils/tests/install' - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using
Re: error
Hi, I have this error: Compilador de optimización versión 13.00.9466 para .NET Framework de Microsoft (R) C/C++ (C) Microsoft Corporation 1984-2001. Reservados todos los derechos. AutoExcel.cpp link /nod:libcpmt.lib kernel32.lib mscoree.lib /out:AutoExcel.exe AutoE xcel.obj link: extra operand `mscoree.lib' Try `link --help' for more information. NMAKE : error grave U1077: 'link' : c?digo devuelto '0x1' Stop. cd .. this is a mscoree.lib error or makefile bad instructions? It looks like your PATH is picking up a different version of a file named link.exe (a POSIX-compliant link from coreutils - do you have something like cygwin or mingw installed?) than what your nmake file was expecting (a helper application with a poorly chosen name related to Microsoft's compiler, but when has POSIX naming conventions ever stopped Microsoft from making bad decisions). I doubt the coreutils list can give you any more help than to suggest that you change your PATH environment variable so that nmake finds Microsoft's link like it was expecting. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Another testsuite nit: `set -'
The testsuite had several uses of `set - $list', such that $list could safely begin with `-'. But 1) POSIX has obsoleted this usage, and 2) in several shells (at least ash and bash), using - instead of -- as the separator gives the shell the right to reset -v and -x, which kills the trace when VERBOSE=yes. In all four cases patched below, it is easily verifiable that the expanded arguments at those points cannot start with -, so a separator is not needed since the expansion will not be confused with options; but if you prefer to use the autoconf approach instead of my patch, rewrite each offending line as `set x $list; shift'. The other portability fix is that on cygwin, mkdir(2) executed from a directory that has ACLs propagates ACLs to the new directory (as a byproduct of how Windows NTFS permissions are mapped to POSIX semantics). There are several other tests in the testsuite that are not tolerant of ACLs, but at least mkdir/perm can be fixed now as long as we are fixing `set -'. $ ls -ld . drwxrwxrwx+ 16 Administrators Domain Users 12288 Apr 26 10:42 ./ $ mkdir dir $ ls -ld dir drwxr-xr-x+ 2 eblake Domain Users 0 Apr 26 10:42 dir/ $ getfacl dir # file: dir # owner: eblake # group: Domain Users user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x 2005-04-26 Eric Blake [EMAIL PROTECTED] (tiny change) * tests/misc/nice (tests): Don't use `set -', it resets -x. * tests/mv/part-hardlink (fail): Likewise. * tests/stty/row-col-1 (tests): Likewise. * tests/mkdir/perm (tests): Likewise. Also, allow for default directory ACLs. -- Eric Blake coreutils.patch Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug]rm.c pwd.c getcwd.c don't work correctly in MSYS
I have compiled a copy of coreutils CVS with msysDVLPR-1.0.0-alpha of MSYS. After I run 'rm -r *' to delete a directory with subdirectory, I deleted everything in the directory except for itself. When I trace into this bug, I found the reason is because of getcwd.c: when it does with a directory which is mounted, the MATCHING_INO (d, thisino) is always false. This is also a problem on modern cygwin, which may explain your problems with MSYS, since MSYS forked from an older version of cygwin. In short, the cygwin code for readdir(2) populates the d_ino member using a hash algorithm, but in stat(2) it populates the inode information with what the underlying OS provides. On Win98, the FAT filesystem has no concept of inode, so cygwin uses the same hash algorithm, and readdir() is accurate. But on WinNT, where NTFS has a valid inode number, stat() and readdir() disagree about a file's inode, and d_ino should be ignored. For cygwin, I worked around the issue by setting jm_cv_struct_dirent_d_ino=no before configuring, to force coreutils to ignore the d_ino member and fall back on stat instead. Ultimately, it would be nicer if the gnulib module for detecting a working d_ino member would detect that cygwin's implementation is broken on NTFS drives. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug]rm.c pwd.c getcwd.c don't work correctly in MSYS
Also, the pwd.c can't get the correct directory. Yes, that sounds like the same issue. Also, does your platform have a reliable getcwd function? If so, why did configure decide not to use it? You may want to further investigate m4/getcwd-path-max.m4, which was changed in CVS to gracefully accept getcwd() when the system refuses relative paths whose absolute length exceeds PATH_MAX. I recall that when I proposed the patch, I only looked for ENAMETOOLONG and ERANGE, because I simultaneously applied a patch to Cygwin to return ENAMETOOLONG instead of EINVAL. MSYS, being a fork from an older version of cygwin, is probably returning EINVAL still. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls -F indicators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 POSIX allows `ls -F' to append other indicators for file types other than directories '/', fifos '|', and symlinks '@'. coreutils ls additionally supports sockets '=', as documented in POSIX application usage as a common extension, but nothing further. Meanwhile, bash TAB-completion with readline's `set visible-stats on' uses '%' for character-special devices and '#' for block-special devices. Compare: $ touch file $ touch exe $ chmod +x exe $ mknod -m 666 null c 1 3 $ mknod -m 666 scd0 b 11 0 $ mkfifo fifo $ mkdir dir $ ln -s dir link $ ls -F [TAB] dir/ exe* fifo| file link@ null% scd0# $ ls -F [RETURN] dir/ exe* fifo| file link@ null scd0 (Hmm - I probably ought to raise a bash bug that readline expansion spacing is inconsistent between one or two spaces when types are listed). Also, POSIX only specifies that `ls -p' denote directories with '/'; it does not specify =@| for sockets, links, and fifos, and does not have the same escape clause of allowing additional symbols that -F does. It would be nice if -F (and --indicator-style=WORD) could support '%' and '#', and -p were made more compliant (or that a defect raised with the austin group to allow -p to support other characters). One final question - ls --color and dircolors support the file type door, coloring it by default like sockets, but I am not familiar with that file type (I doubt cygwin supports it). What systems have doors, and should doors also have a classification character? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcjSd84KuGfSFAYARAgyOAJ45P391hWeKNb+Vd5vQyWQRmr1KSQCgyHP/ o3jfcmY6zAYdjyK3aVPoIrg= =RcXH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
stat(1) [was: Another testsuite nit: `set -']
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 4/29/2005 3:51 PM: * tests/mkdir/perm: Don't use 'set -'. Simplify test construction. Work even if the underyling system attaches ACLs to new dirs. @@ -71,11 +73,11 @@ for p in empty -p; do mkdir $p $mode parent/sub || fail=1 -perms=`ls -ld parent | sed 's/ .*//'` +perms=`ls -ld parent | sed 's/ .*//; s/+$//'` I had some further thoughts about this. Forking is expensive in cygwin, so I was experimenting with spawning one less process by doing: perms=`stat -c %A parent` It appears that only ls is appending the '+' for ACLs; should stat also be given a format character for printing whether a file has additional permissions? For the purposes of the testsuite, making it separate from %A is nice, because then you don't have to strip a trailing '+' (or any of the other trailing information in a long ls listing) when determining a file's permissions. $ ls -ld . drwxr-xr-x+ 14 eblake None 0 May 2 06:25 . $ stat -c %A . drwxr-xr-x stat(1) doesn't appear to be in any standards, and coreutils stat has a different set of options than either the zsh builtin or the FreeBSD version (http://tautology.org/software/man/stat). Nice things about the FreeBSD version that coreutils does not have: - -F: display like `ls -lTF' - -n: supress newline between files - -q: supress errors from stat/lstat - -f format: (similar to coreutils -c without -f) allows flags and width between % and character %p file type and permissions %l (similar to coreutils %h) %r device number for character and block devices %a (similar to coreutils %x) %m (similar to coreutils %y) %c (similar to coreutils %z) %B inode creation time (not all filesystems support this) %z (similar to coreutils %s) %k (similar to coreutils %o) %f user-defined flags %v inode generation number %T file type indicator (*/=@|%) %Y symlink target %Z major,minor on special devices, size on others %% single % (undocumented in coreutils) - -l: display like `ls -lT' - -r: raw stat field entries (is this like coreutils -t?) - -s: quote output, suitable for shell variable initialization - -x: more verbose - -t timefmt: format dates with input similar to date(1) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCdiVE84KuGfSFAYARAgZKAJ9d7R7JDCwBf0CibbU6KmMg6jNPWACfbEZs XSDdPGdLAV2bC/xisN1HlFM= =nVWv -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -F indicators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 4/29/2005 3:07 PM: Eric Blake [EMAIL PROTECTED] writes: bash TAB-completion with readline's `set visible-stats on' uses '%' for character-special devices and '#' for block-special devices. Aack. FreeBSD ls uses % for whiteouts, and nothing for special files. I'd rather not have gratuitous incompatibility. I take it whiteouts are another form of special file, unique to FreeBSD? What about proposing '^' (with the mnemonic pronounciation caret) as the character-special indicator, to the bash mailing list? And can coreutils detect whiteouts on FreeBSD systems, to offer them '%' and colorization status (similar to how Solaris doors get '' and dircolors recognizes DOORS)? Also, I noticed that the comments in lib/filemode.c list a few filetypes for the first character of `ls -l' that are not mentioned in the info pages, such as 'n' for network special file. Do any of the other recognized file types deserve their own indicator flag? + ls changes: + +-p now appends '/' only to directories; it is equivalent to the +new option --indicator-style=directory. Use --file-type or +--indicator-style=file-type to get -p's old behavior. + Previously, `ls --classify' was short for `ls --indicator-style=classify', and `ls --file-type' was short for `ls --indicator-style=file-type'. But `ls --directory' already exists; is there a better choice of indicator names to allow parallelism for a shorter spelling of `ls - --indicator-style=directory'? Perhaps `ls --mark-directory'? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCdihG84KuGfSFAYARAqebAKDOHcObNcDf5S9PUU+Gy3u6rio4EQCfWy/K 9Dy+lqOQF0SR3QLalWTNJwQ= =cOuy -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pierre A. Humblet on 5/2/2005 9:22 PM: According to the Cygwin Faq, * Why doesn't `mkdir -p' work on a network share? Unfortunately, you cannot do something like this: bash$ mkdir -p //MACHINE/Share/path/to/new/dir mkdir: cannot create directory `//MACHINE': No such file or directory This is because mkdir checks for the existence of each directory on the path, creating them as necessary. Since `//MACHINE' is not a directory (you can't cd to it either), mkdir tries to create it, and fails. ** This behavior would be fine with me, but the latest mkdir (GNU coreutils) 5.3.0 creates /MACHINE/Share/path/to/new/dir and returns 0 Pierre It appears you have uncovered an upstream bug - in line 210 of CVS coreutils/lib/makepath.c (unchanged from 5.3.0), `mkdir -p' is attempting an optimization by blindly changing directory to / if the first character is '/', without regards to whether there is a leading // such that changing to / violates POSIX naming semantics. In my opinion, it should be possible to rewrite the algorithm to make even your test case works, eliminating the cygwin FAQ entry: rather than starting at the left and making sure each path component exists, the algorithm could start at the right and successively prune each rightmost component until it no longer gets ENOENT (or gets to the empty string), then build back up from that point. Then, even though //MACHINE does not resolve to a directory, `mkdir -p //MACHINE/Share/existing/nonexisting' only has to check whether //MACHINE/Share/existing exists, and create nonexisting from there, rather than starting all the way from the problematic /, //, or //MACHINE. The only drawback to this approach is that it would then require up to n stat() calls to decide where to start making directories, each processing O(n) names, which is the exact O(n^2) syscall overhead that the code was optimized to try to avoid by starting blindly at the leftmost component. The only other approach I can think of is to special case leading // (at least on cygwin, leading // should start after //MACHINE/Share/), but not all POSIX-compliant hosts have the same semantics for leading //, so I don't know how well such a special case would fold into upstream coreutils. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFCd3cZ84KuGfSFAYARAqf8AJ4waeVK7NWOh0D4fz84LD5jcBmPpQCY9blL 6lOcqZkvuNWndvgAjElQ9A== =sDhN -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chmod -w file now complains if file is still writable afterwards
This is a common trap for novices to fall into, and I think it'd be better if chmod diagnosed the mistake, in addition to performing the requested action. I just checked POSIX, and it allows chmod to diagnose errors like chmod -w file so I installed the following patch. It took me a while to follow your logic of how POSIX allows this, so I'm stating why I am in agreement. The only option chmod is required to support is -R, so we can define our own semantics for extension options such as -w, -r, etc., where our extension options happen to look like valid mode strings. There is definitely a parsing difference between `chmod -- any-mode file' or `chmod non-dash-mode file' with 0 options and 2 arguments, and `chmod -dash-mode file' with 1 option and 1 argument, and POSIX only dictates the behavior of the first. Other questions, though - with our extension options, should we interpret `chmod -w a+x foo' the same as `chmod -- -w ./a+x ./foo' or like `chmod -- -w,a+x ./foo'? Put in other words, if the first of multiple non-option arguments matches a mode, should it be treated as a mode or a file when extension options are present. Also, POSIX allows modes that look like long options - can the code be made to treat `chmod --w foo' the same as it would `chmod -w foo' by seeing if unrecognized long options match a valid mode string? Another option would be for chmod -w file to silently adjust itself to behave like chmod a-w file; POSIX allows that too. If you think that's better I could install a patch along those lines instead. I tend to favor your existing patch as the correct approach. I would find it confusing if the extension syntax `chmod -w file' behaved differently than the compliant syntax `chmod -- -w file' on which permissions it affected, unless we documented the -w extension better. Speaking of which, the `chmod --help' wording could be improved (perhaps with examples); it does not mention -w, -r, etc. as being extension options, and wrongly states that one or more of the letters ugoa is required as who, and one or more of the letters rwxXstugo is required as perm/permcopy. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/5/2005 2:09 AM:
What happens with the file names //, //MACHINE, and
//MACHINE/Share in Cygwin? Don't they appear to be directories,
albeit directories that you can't alter? If not, that suggests a bug
in Cygwin.
By itself, // is currently treated as a synonym for /. I think that
behavior was chosen because of the number of programs that don't respect
POSIX semantics, but it means that chdir(//) is currently no different
from chdir(/), other than getcwd(2) knows the spelling difference (the
two directories have the same readdir() contents). At least cygwin obeys
POSIX in that after chdir(///), getcwd() returns /. //MACHINE
currently generates ENOENT, whether or not there is a server on the
network with that name, and mkdir(2), stat(2), and chdir(2) with an
argument of //MACHINE fail. But //Machine/Share is a valid directory if
it resolves, (if it doesn't resolve, it hangs for several seconds, then
times out with No such host or network path, ENOSHARE, invented for cygwin).
Yes, I agree that it would be nicer if cygwin knew how to treat // as
distinct from /, such that readdir() on // returned a listing of currently
accessible hosts and acted as a read-only device. I also agree that it
would be nicer if cygwin knew how to treat //MACHINE as a read-only
directory if //MACHINE is detected on the network, and listed the shares
available from there. I think that the Windows-provided functions
NetShareEnum and WNetEnumResource appear to provide what is needed to do
this, but I wouldn't know how to go about patching cygwin to use them.
That being said, it can't hurt to add the following minor workaround,
(which would work on Domain OS anyway :-), so I installed it.
2005-05-05 Paul Eggert [EMAIL PROTECTED]
* makepath.c (make_path): chdir to //, not /, if the file name
starts with exactly two slashes. This doesn't solve the problem
in general but it's better than nothing. Problem reported by
Pierre A. Humblet via Eric Blake.
Below is the patch I came up with to fix the issue on cygwin, prior to
your reply. By the way, the coreutils anon CVS mirror syncronization
appears to be hung again, I haven't seen any of your patches show up on
savannah.gnu.org since April 22nd. Since it is __CYGWIN__ specific, and
since your minor patch will work if cygwin were patched to treat //MACHINE
as a directory (like Domain OS did), I don't know if you want to fold my
patch into the official repository.
Index: lib/makepath.c
===
RCS file: /cvsroot/coreutils/coreutils/lib/makepath.c,v
retrieving revision 1.60
diff -u -p -r1.60 makepath.c
- --- lib/makepath.c 30 Jul 2004 20:29:01 - 1.60
+++ lib/makepath.c 4 May 2005 13:16:23 -
@@ -212,6 +212,36 @@ make_path (const char *argpath,
slash = dirpath;
+#ifdef __CYGWIN__
+ /* Special case for //server/share prefix. */
+ if (*dirpath == '/' dirpath[1] == '/' dirpath[2]
+ dirpath[2] != '/')
+ {
+ slash = strchr (dirpath[2], '/');
+ if (slash == NULL)
+ {
+ error (0, 0, _(%s requires a share name), quote (dirpath));
+ CLEANUP;
+ return false;
+ }
+ while (*slash == '/')
+ slash++;
+ slash = strchr (slash, '/');
+ if (slash == NULL)
+ {
+ do_chdir = false;
+ slash = strchr (dirpath, '\0');
+ }
+ else if (do_chdir)
+ {
+ *slash = '\0';
+ if (chdir (dirpath) 0)
+ do_chdir = false;
+ *slash = '/';
+ }
+ }
+#endif /* __CYGWIN__ */
+
/* Skip over leading slashes. */
while (*slash == '/')
slash++;
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFCehR884KuGfSFAYARAtXJAJURjkAzv/72pxEOE0WklFBQZIf/AJ9sZ/VX
gMBtqxqy/CGzdeOZDn+faw==
=z4qU
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/5/2005 2:09 AM:
@@ -207,8 +207,14 @@ make_path (const char *argpath,
/* If we've saved the cwd and DIRPATH is an absolute pathname,
we must chdir to `/' in order to enable the chdir optimization.
So if chdir (/) fails, turn off the optimization. */
- if (do_chdir *dirpath == '/' chdir (/) 0)
- do_chdir = false;
+ if (do_chdir dirpath[0] == '/')
+ {
+ /* POSIX says // might be special, so chdir to // if the
+ file name starts with exactly two slashes. */
+ char const *root = // + (dirpath[1] != '/' || dirpath[2] == '/');
Oops - buffer overflow bug. dirpath[2] is past the end of the string on
dirpath of /, since you are only testing for dirpath[1] != '/'. Try
this instead:
char const *root = // + (dirpath[1] != '/'
|| (*dirpath[1] dirpath[2] == '/'));
True, dirpath was created via alloca, which on most architectures
allocates on word boundaries, so dirpath[2] is probably safe to reference,
but that is beside the point. For that matter, since path names can be
arbitrary length (on some platforms), allocating dirpath with alloca is
asking for problems with the potential of stack overflow.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCetkz84KuGfSFAYARAveaAJ4nczwBy9G9D4qct3z4dhSo+C5YIACg0aMI
P2Dbg6xbPaoYLPR51j53DnA=
=TGwj
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 5/5/2005 9:47 PM: Oops - buffer overflow bug. dirpath[2] is past the end of the string on dirpath of /, If dirpath is /, then dirpath[1] != '/' is true, so dirpath[2] isn't evaluated. Oh well - chalk that one up to me not reading closely enough after a long day. I should learn not to hit send before re-reading :) But my other comment about dirpath being allocated with alloca on potentially unlimited length input is still an issue. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeuqU84KuGfSFAYARAsPuAJ0Sz/Z7WqJElt5r0CY2iQSW23NjhgCfXQcl 1ruNPfUt1egZkV7z1m98bTc= =tl8M -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DD converts LF - CR / LF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Brian Dessent on 5/6/2005 2:06 AM:
Sebastian Schuberth wrote:
my mounts are all text mode, i.e. the Default Text File
Type is DOS. Nevertheless, shouldn't
dd if=test_unix.txt of=text.txt
create an exact copy of test_unix.txt? It seems DD doesn't open the
file in binary mode
I already tried several of the conv= arguments to DD with no luck.
Yeah, that does seem a bit broken. You can solve that with something
like the following:
--- dd.c.orig 2005-05-06 01:03:01.12500 -0700
+++ dd.c2005-05-06 01:00:07.265625000 -0700
@@ -136,8 +136,12 @@
static int conversions_mask = 0;
/* Open flags for the input and output files. */
-static int input_flags = 0;
-static int output_flags = 0;
+#ifndef O_BINARY
+#define O_BINARY 0
+#endif
+
+static int input_flags = O_BINARY;
+static int output_flags = O_BINARY;
/* Status flags for what is printed to stderr. */
static int status_flags = 0;
-
It would be up to the coreutils maintainer to decide what to do about
this. It could be handled in a number of ways.
Brian
Predefining O_BINARY as the default input_flags and output_flags is a
stopgap measure. While it is fine for other programs, such as od, to
always open in binary mode, I think that dd should be more flexible as it
already can specify so many other fine-tuning details. It would be nicer
if iflag= and oflag= supported text and binary as supported flags (no-ops
on platforms where there is no difference). Or maybe introduce new
keywords imode= and omode=, since it is not clear whether fcntl(fd,
F_SETFL, O_BINARY) will work, or whether modes must be set with
SET_MODE(fd, O_BINARY) from system.h. Also, since O_BINARY and O_TEXT are
mutually exclusive (when O_BINARY is defined, you can't set the mode to
O_BINARY|O_TEXT), it would add a layer of complication to parsing iflags
to ensure that an incompatible mode is not chosen.
There is still the question on cygwin whether an unspecified text/binary
mode should always default to binary, or should default to the underlying
default for that particular mount. Meanwhile, I noticed that cygwin
permits open(foo, O_RDWR | O_BINARY | O_TEXT), although I don't know
which of the two modes it chose; I think it should instead return EINVAL
like setmode(fd, O_BINARY | O_TEXT) does.
Here's a cygwin-local patch (against the 5.3.0 tarball) that adds imode=
and omode=, and which defaults to binary mode if unspecified. I'll try to
release coreutils-5.3.0-6 to cygwin in the next week, including this fix
and a `mkdir -p' fix. I'm cc'ing bug-coreutils in case it is decided to
be a good idea to use as a starting point for folding in upstream (of
course, it would also need NEWS and coreutils.texi documentation, and
updated to apply against CVS HEAD).
2005-05-06 Eric Blake [EMAIL PROTECTED]
Add imode= and omode= to dd:
* src/dd.c (input_mode, output_mode, modes, set_fd_mode):
New variables and method.
(usage) [O_BINARY]: Document new args.
(scanargs) [O_BINARY]: Parse new imode and omode args.
(main): Set file mode.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCe3DJ84KuGfSFAYARApZbAKCaEJJqwJ9I2UCXy5HarHMJXKHqSACdFNyN
XurPMrVxdRcFj+cqepzaSnw=
=m/hB
-END PGP SIGNATURE-
--- ../coreutils-5.3.0.orig/src/dd.c2004-11-22 07:14:44.0 -0700
+++ src/dd.c2005-05-06 07:17:15.073875000 -0600
@@ -139,6 +139,10 @@
static int input_flags = 0;
static int output_flags = 0;
+/* Mode flags for the input and output files. */
+static int input_mode = 0;
+static int output_mode = 0;
+
/* Status flags for what is printed to stderr. */
static int status_flags = 0;
@@ -237,6 +241,16 @@
{, 0}
};
+#if O_BINARY
+static struct symbol_value const modes[] =
+{
+ {binary,O_BINARY},
+ {text, O_TEXT},
+ {, 0}
+};
+#endif
+
+
/* Status, for status= */
static struct symbol_value const statuses[] =
{
@@ -380,9 +394,23 @@
fputs (_(\
if=FILE read from FILE instead of stdin\n\
iflag=FLAGS read as per the comma separated symbol list\n\
+), stdout);
+#if O_BINARY
+ fputs (_(\
+ imode=MODE open input in MODE\n\
+), stdout);
+#endif
+ fputs (_(\
obs=BYTES write BYTES bytes at a time\n\
of=FILE write to FILE instead of stdout\n\
oflag=FLAGS write as per the comma separated symbol list\n\
+), stdout);
+#if O_BINARY
+ fputs (_(\
+ omode=MODE open output in MODE\n\
+), stdout);
+#endif
+ fputs (_(\
seek=BLOCKS skip BLOCKS obs-sized blocks at start of output\n\
skip=BLOCKS skip BLOCKS ibs-sized blocks at start of input\n\
status=noxfer suppress
Re: DD converts LF - CR / LF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 5/6/2005 12:01 PM: That looks pretty complicated. How about if we just rely on open and fcntl to do the work? If they don't work, they should. I installed this into coreutils: 2005-05-06 Paul Eggert [EMAIL PROTECTED] * NEWS: dd has new iflag= and oflag= flags binary and text. * doc/coreutils.texi (dd invocation): Document it. * src/dd.c (flags, usage): Support it. That's okay for a start, but it now defaults to the underlying mount mode when the user does not specify binary or text. In my opinion, dd should default to binary when neither text nor binary is specified (of course, that makes iflag=binary pretty much a no-op). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCfNtI84KuGfSFAYARAvJTAJ9qZymfD8tj84OIFBORuo1+Nyix5wCfXoqQ R21yy4vx9YA1YIDr5oHG7MI= =wjhL -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Fwd: Strange-Dangerous behaviour in Cygwin]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Relevant clips from this cygwin bug report. When tty settings are weird (I'm not sure whether the bug is in cygwin, xterm, or just bad tty settings that could be reproduced elsewhere), backspace only repositions the cursor on screen, so that the actual buffer read by yesno() can contain y\bn instead of n. Is it possible for lib/yesno.c to be a little more paranoid and check that there are not embedded characters normally used in terminal editing that would undo the first character? - Original Message Subject: Strange-Dangerous behaviour in Cygwin Date: Sat, 07 May 2005 17:52:10 +0200 (MET DST) From: Angelo Graziosi [EMAIL PROTECTED] To: cygwin@cygwin.com, [EMAIL PROTECTED] I discovered the following strange behaviour in bash and xterm (startxwin) shells: Suppose having alias rm='rm -i' alias cp='cp -i -p' alias mv='mv -i' then rm foo.txt writes rm: remove regular file `foo.txt'? Suppose that I does not want to remove it but mistaking I type y rm: remove regular file `foo.txt'? y Before the RETURN, I see the error so I correct, with BACKSPACE, y in n: BACKSPACE does not delete y as aspected but it only shifts the cursor on y and when I type n and then RETURN the file foo.txt is REMOVED! - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCfOsh84KuGfSFAYARAshbAJ9ryQbHUu1+3cAN2pWiMY+ElmeR/wCeMAs3 gp1Dstsp/0gDFvup0MTauJY= =2MBv -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/7/2005 9:43 AM: Which Bash bug is that? Bash is the most important program for which 'that chdir(//) is currently no different from chdir(/)'. Is that a bug in bash or in cygwin, though? The comments for cygwin bash-2.05b-17 mention that a patch from Corinna Vinschen was applied to avoid turning '/' into '//' when converting/checking path. And `strace bash -c 'chdir //' shows: 32 20141553 [main] bash 1564 mount_info::conv_to_posix_path: // = conv_to_posix_path (//) 112 20141665 [main] bash 1564 chdir: dir '//' 29 20141694 [main] bash 1564 normalize_posix_path: src // 30 20141724 [main] bash 1564 normalize_posix_path: / = normalize_posix_path (//) 29 20141753 [main] bash 1564 mount_info::conv_to_win32_path: conv_to_win32_path (/) 32 20141785 [main] bash 1564 set_flags: flags: binary (0x2) 65 20141850 [main] bash 1564 mount_info::conv_to_win32_path: src_path /, dst c:\cygwin, flags 0xA, rc 0 89 20141939 [main] bash 1564 symlink_info::check: not a symlink 32 20141971 [main] bash 1564 symlink_info::check: 0 = symlink.check (c:\cygwin, 0x22E6D0) (0xA) 32 20142003 [main] bash 1564 path_conv::check: this-path(c:\cygwin), has_acls(1) 76 20142079 [main] bash 1564 chdir: 0 = chdir() cygheap-cwd.posix '/' native 'c:\cygwin' And this simple trace backs that up: $ cd // $ pwd // $ /bin/pwd / So it was the cygwin normalization code that turned '//' into '/', while bash thinks the current dir is '//'. What breaks if the cygwin chdir() normalization code is changed to not turn '//' into '/'? Our track record for getting cygwin fixes into bash has been mixed. I believe that someone has tried to get this fixed previously, along with an even more serious problem with bash getting confused by quick pid reuse but I believe that both problem still exist in bash 3.0. Does bash 3.0 still have the bug that Corinna's patch to 2.05b fixed? At any rate, there is no official cygwin bash 3.0, because there has still been no volunteer to step up and produce a cygwin compilation of bash. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCfPX184KuGfSFAYARAtRIAKDYJxaPVMFBvTBky1Pn0Ql2C9YM8wCggSWm eGq3zgHS7Slnz12CrIsApTs= =/1q1 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Filename Globbing issues on Win32?
I'm actually using the coreutils compiled and bundled with the GnuWin32 and UnxUtils projects. Both projects still refer back to the original Gnu coreutils lists. I may crosspost this thread over to those guys if I'm not totally crazy on this. :) Your examples were from the Windows shell, which has non-POSIX quoting rules and does not behave like any of the POSIX-compliant shells that anyone on this list uses, so no one here has enough familiarity with it to answer your questions. Ask the GnuWin32 or UnxUtils lists for how to get Windows shell quoting to do what you want it to (if it is even possible in those ports). Or consider using cygwin, so that you can use POSIX quoting rules even on Windows (which is what I personally do). You won't get much more help from this list. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
dirent.d_ino check
The check in m4/d-ino.m4 is currently just a link test, which means it fails to detect that cygwin returns bogus d_ino data on readdir() of NTFS filesystems (but it matches stat() on FAT filesystems). I'm not sure how to test for a working d_ino in cross-compilation, so the fallback to my new run test is the existing link test. 2005-05-09 Eric Blake [EMAIL PROTECTED] * d-ino.m4: Add run test to detect broken cygwin d_ino. -- Eric Blake coreutils.patch Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dirent.d_ino check
As I understand it, that test will work only if you happen to run it in an NTFS file system. How about if we just modify the test to always report failure when building for Cygwin? That's simple and it's better than sometimes returning the wrong answer. That's fine for now, and much simpler (but will need revisiting if cygwin ever fixes this POSIX-compliance bug). Apparently, Windows XP is much more efficient than Windows NT at reading inodes off an NTFS drive, and one of the cygwin developers is contemplating a patch that would enable correct readdir() inodes for NTFS, but only on XP. If that patch goes in, should readdir() be changed in NT to always set d_ino to 0 on NTFS? It looks like everywhere that coreutils looks for d_ino, it uses macros that default to 0 on systems without support, so that d_ino of 0 falls back to the stat() family. If that fallback is common practice among portable programs, then having cygwin return 0 rather than a bogus hash when the cost of determining the inode is prohibitive would be preferable for allowing dynamic runtime detection rather than a fixed autoconf run test. And on FAT, where the hash IS the inode, cygwin could get the speed benefit from having a valid d_ino. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Make Check on coreutils, darwin failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Adam Price on 5/9/2005 11:39 PM: Making check in touch make check-TESTS PASS: relative 0a1 touch: setting times of `/': Permission denied FAIL: not-owner I've noticed that cygwin also tends to fail this test, because the typical cygwin user installed / themselves (as c:\cygwin) and has write access to change /. I don't know if there is a better approach to finding a directory that the user does not have rights to (cygwin will soon have // appear as a directory with read-only properties, so // might work, but doesn't generalize well). Perhaps something like this is needed in tests/touch/not-owner: if test `stat -c %u /` = `id -u` ; then echo Skipping because / is owned by user 2 (exit 77); exit 77 fi group=`stat -c %g /` for g in `id -G` ; do if test $group = $g ; then echo Skipping because / belongs to user's group 2 (exit 77); exit 77 fi done - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgKqD84KuGfSFAYARAuuXAJ0Vo+uBwLnjzUXkK6YGeXN4kef1SwCgipI5 FwdGOXEIQ1a+eZ2lKf5KLuI= =ZqOw -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
dd and binary mode
After further thought and discussion on the cygwin list, I'm convinced that dd should default to binary mode (on non-ttys) on systems that have a distinct text mode. Otherwise, consider the harmful effects of `dd of=/dev/sda if=mbr' to overwrite the master boot record, if the user did not realize that mbr was on a text-mode mount. dd(1) is too commonly associated with binary files, similar to od(1), to risk making it default according to the underlying mount mode. I noticed that system.h defines SET_BINARY to avoid changing the mode of ttys, so by using that, iflag=binary is not necessarily a no-op. But in general, to get text mode, a user should need to explicitly ask for it with iflag=text. Also, cygwin requires the use of setmode() to change a file's mode; fcntl(F_GETFL) shows the current mode, but fcntl(F_SETFL) masks mode and permissions bits, having no effect on the mode. POSIX does mention that fcntl(F_SETFL) only has specified results on file status bits. One question remains - system.h assumes that the return value of SET_MODE should be ignored (when O_BINARY is undefined, SET_MODE is (void)0). But on cygwin, setmode can return -1 on failure with EBADF or EINVAL. Should this assumption in system.h be changed, or my patch tweaked to ignore the value of SET_MODE? 2005-05-13 Eric Blake [EMAIL PROTECTED] (tiny change) * src/dd.c (set_fd_flags): Handle mode changes with SET_MODE, since Cygwin cannot change mode with fcntl. (main): Default to binary if [io]flag= did not choose mode. -- Eric Blake coreutils.patch Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd and binary mode
open files sort - POSIX requires text input split - POSIX requires binary input stat - doesn't open files stty - doesn't open files su - doesn't open files (cygwin doesn't support su; and the question was raised earlier whether coreutils should drop su or add newgrp) sum - non-standard, but like cksum needs binary input sync - doesn't open files tac - non-standard, but like cat operates on binary input tail - POSIX requires that -c operates on binary input, otherwise on text input tee - POSIX requires binary input and output test - doesn't open files touch - doesn't open files tr - POSIX requires binary input true - doesn't open files tsort - POSIX requires text input tty - doesn't open files uname - doesn't open files unexpand - POSIX requires text input uniq - POSIX requires text input unlink - doesn't open files uptime - doesn't open files users - non-standard, but /var/run/utmp should probably be opened in binary mode vdir - doesn't open files wc - POSIX requires binary input who - doesn't open files whoami - doesn't open files yes - doesn't open files Is there some way that we can simplify this by using wrapper functions on DOS-like hosts? I'd rather get rid of the SETMODE and SET_BINARY macros entirely. If Cygwin open or fcntl doesn't do the obvious thing with O_TEXT and O_BINARY, let's define a wrapper function, used only on cygwin, that does the right thing. open does the right thing. The problem is that fcntl(fd,F_SETFL,fcntl(fd,F_GETFL)|O_BINARY) will not work, since O_BINARY is not an additive property, but a mutually exclusive property with O_TEXT. Whether you used O_BINARY, O_TEXT, or nothing with the original open(), fcntl(F_GETFL) will always return O_BINARY or O_TEXT in its list of flags. And even if cygwin is patched to let fcntl(F_SETFL,O_BINARY) change the mode to binary, it will have to reject fcntl(F_SETFL,O_BINARY|O_TEXT). Hence the current use of setmode(mode), which returns EINVAL unless mode is exactly O_BINARY, O_TEXT, or 0 (meaning no change). I agree that a wrapper might help, but the wrapper would need slightly different semantics than how fcntl(F_SETFL) is used in dd.c, because of the mutually exclusive nature of O_BINARY and O_TEXT. Your patch assumes that (O_BINARY != 0 O_TEXT != 0); is this really true on all platforms? It seems to me that one could be zero. system.h keys solely off of O_BINARY - if O_BINARY is non-zero, then O_TEXT is required to also exist (and it is probably also non-zero). If O_BINARY doesn't exist or is 0, then system.h makes both O_BINARY and O_TEXT be 0, to avoid later #ifdef'ery. My patch always treated the combination of (O_BINARY|O_TEXT), which should easily be optimized out as 0 on platforms without O_BINARY; and should work fine even if there is a platform with non-zero O_BINARY but zero O_TEXT. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCifIF84KuGfSFAYARArZZAKCDotpvCtmF64M5CSizVfBCTWuycwCeK559 OxEtCVcmNQIVzS+dc9DmvBg= =drvs -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm: avoiding a race condition on non-glibc systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 5/13/2005 4:55 PM: 2005-05-13 Paul Eggert [EMAIL PROTECTED] * m4/prereqs.m4 (gl_PREREQ): Require gl_UNLINKDIR. * src/remove.c: Include unlinkdir.h. (UNLINK_CAN_UNLINK_DIRS): Remove. (remove_entry): Use cannot_unlink_dirs () rather than UNLINK_CAN_UNLINK_DIRS. * lib/unlinkdir.c, lib/unlinkdir.h: New files. * m4/unlinkdir.m4: New file. + /* If we happen to know that FILENAME is a directory, return now + and let the caller remove it -- this saves the overhead of a failed + unlink call. If FILENAME is a command-line argument, then dp is NULL, + so we'll first try to unlink it. Using unlink here is ok, because it + cannot remove a directory. */ + if ((dp DT_IS_DIR (dp)) || is_dir == T_YES) + return RM_NONEMPTY_DIR; + This change broke cygwin. Cygwin does not have struct dirent.d_type, so DT_IS_DIR is defined as do_not_use_this_macro. I think protecting this if statement with HAVE_STRUCT_DIRENT_D_TYPE, and letting cygwin fall through to the unlink, will fix the problem. 2005-05-16 Eric Blake [EMAIL PROTECTED] * src/remove.c (remove_entry) [! HAVE_STRUCT_DIRENT_D_TYPE]: Fix breakage on Cygwin when checking for directory. Index: src/remove.c === RCS file: /cvsroot/coreutils/coreutils/src/remove.c,v retrieving revision 1.125 diff -u -p -r1.125 remove.c - --- src/remove.c14 May 2005 08:05:35 - 1.125 +++ src/remove.c16 May 2005 13:21:05 - @@ -755,7 +755,11 @@ remove_entry (Dirstack_state const *ds, unlink call. If FILENAME is a command-line argument, then dp is NULL, so we'll first try to unlink it. Using unlink here is ok, because it cannot remove a directory. */ - - if ((dp DT_IS_DIR (dp)) || is_dir == T_YES) + if (is_dir == T_YES +#if HAVE_STRUCT_DIRENT_D_TYPE + || (dp DT_IS_DIR (dp)) +#endif + ) return RM_NONEMPTY_DIR; DO_UNLINK (filename, x); - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCiJ6m84KuGfSFAYARAoaSAJ9PwT7Nqgda/rvCCdC2BXCPMqqldACfTtL6 pkcs5bvT1FNKdT34REcWmLg= =EnkT -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir when target exists and is a broken symlink
ln -s nonexistent foo There could be some kind of -f, --follow option so that mkdir will create the directory pointed to. You'd probably use it together with -p. Then 'mkdir -fp' would be a way to try everything sensible to make sure the destination exists and can be used as a directory (ie, is a directory itself or a symlink to one). This sounds somewhat similar to cp -f, --force. cp uses slightly different semantics, required by POSIX (rather than try to create the new file at the location specified by the dangling symlink, it unlinks the symlink and creates the new file in its place). I would lean more toward force semantics than follow semantics if `mkdir -fp' were supported. In particular, how would follow semantics behave with `mkdir -fp circular'? I note that 'touch foo' when foo is a broken symlink will create the link destination if possible Hmm, you may have unconvered a POSIX bug or coreutils compliance bug: POSIX requires that touch do the equivalent of calling creat() if the file does not exist, then call utime() whether or not creat() was called. A broken symlink exists, so step one should be skipped, then in step two, utime() should fail with ENOENT when trying to resolve the (still) broken symlink. But coreutils is using open(O_CREAT) as the simultaneous check for existance and replacement call for creat(). Normally, this is identical, but in the case of a broken symlink, it is not (remember, POSIX states that open(foo, O_CREAT|O_EXCL) must fail with EEXIST; but without O_EXCL, it follows the link as if open(nonexistent, O_CREAT) had been called, thus creating the target). Then in step two, since nonexistent now exists, futimens (coreutils much nicer replacement for utime) is successfully changing nonexistent's time. This may be an unintentional oversight in POSIX, worthy of bringing before the Austin group, because the semantics of touch populating a previously dangling symlink are useful. Furthermore, create() is equal to open(O_WRONLY|O_CREAT|O_TRUNC), but coreutils is using open(O_WRONLY|O_CREAT|O_NONBLOCK|O_NOCTTY). The omission of O_TRUNC is okay (it has no semantics when the file did not exist, touch should only create the file if it did not exist, and checking for existance with O_TRUNC is destructive). But the addition of O_NONBLOCK and O_NOCTTY, while reasonable, are not allowed by the strict reading. Finally, a related feature request: on systems that support lutime() and family (and where lstat() provides meaningful times on the symlink), touch should probably support -L,--logical and -P,--physical to control whether the time being touched is of the actual symlink or of its target. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir when target exists and is a broken symlink
I note that 'touch foo' when foo is a broken symlink will create the link destination if possible (though without making any directories, obviously). POSIX requires this, but it is arguably a misfeature, due to the security issues mentioned. Perhaps we should add an option to touch to disable it? See my earlier reply to why I think POSIX requires the exact opposite - that `touch dangling' must fail, not create the new file pointed to by dangling. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in cat 5.3.0 (cygwin) on XP SP2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tristan Savatier on 5/18/2005 4:39 PM: when 'cat' is passed several text files as parameters, it will add the invisible control character '^M' at the end of each lines of each file except the first file. Cygwin line-ending problems should probably first be discussed on cygwinatcygwindotcom. Furthermore, it works just fine for me (I don't think there is a bug, either in the cygwin distribution or upstream in this list), it is probably a question of whether your files live on a text mount, and whether they already had ^M's to begin with. emacs has the nice habit of suppressing ^M if EVERY line of the file has it (DOS mode), but when only some lines have it (those lines from file2 and file3, but not the lines from file1), you are in mixed mode and emacs reversts to unix display. Also, commands such as d2u are your friend when working with mixed line ending machines. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCjIeM84KuGfSFAYARAqx2AJ4inZePYVIpSBu73KoM9URk/P3T4ACggogQ 6LD9dh+uA8+4jv3mXzWKyA8= =VI57 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
classification indicator for character-special files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Configuration Information: Machine: i686 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' - -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc' - -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL - -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I. -I./include -I./lib -g -O2 uname output: CYGWIN_NT-5.1 LOUNGE 1.5.16(0.128/4/2) 2005-04-25 20:26 i686 unknown unknown Cygwin Machine Type: i686-pc-cygwin Bash Version: 3.0 Patch Level: 16 Release Status: release Description: POSIX allows `ls -F' to use other characters for file types beyond directories, executables, fifos, and symlinks. I recently proposed changing coreutils by copying bash's use of '%' and '#' for character- and block-special files when .inputrc contains 'set visible-stats on'. But Paul Eggert pointed out that FreeBSD already uses '%' to indicate whiteouts on union mounts. Further discussion proposed using '^' for character-special files (since caret serves as a good mnemonic for character, and looks somewhat like a rotated 'c'). Read the thread at: http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg6.html Could you please change bash's indicator for character-special files to be unambiguous with whiteouts, and so that coreutils and bash can be consistent even on systems with union mounts and whiteout files? While you are at it, notice that the spacing of completion output is not as uniform as the spacing from `ls -F'. Repeat-By: $ cat ~/.inputrc set visible-stats on $ touch file $ touch exe $ chmod +x exe $ mknod -m 666 null c 1 3 $ mknod -m 666 scd0 b 11 0 $ mkfifo fifo $ mkdir dir $ ln -s dir link $ ls -F [TAB] dir/ exe* fifo| file link@ null% scd0# $ ls -F [RETURN] dir/ exe* fifo| file link@ null scd0 Note that the yet unreleased coreutils 5.3.1 will only include the patch to use '^' and '#' if it will match a future version of bash. Fix: - --- lib/readline/complete.c~2004-07-01 11:57:58.0 -0600 +++ lib/readline/complete.c 2005-05-19 21:11:13.729625000 -0600 @@ -492,7 +492,7 @@ character = '/'; #if defined (S_ISCHR) else if (S_ISCHR (finfo.st_mode)) - -character = '%'; +character = '^'; #endif /* S_ISCHR */ #if defined (S_ISBLK) else if (S_ISBLK (finfo.st_mode)) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCjVst84KuGfSFAYARAmG+AJ92NpTL067dPCcraJZa0/G9CdLhYQCgw4CA lY0bkn1m0o3f4h34jk0tjgQ= =LO0J -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
exit status of rm
POSIX requires that rm have an argument, but also that it exit with 0 status if All of the named directory entries for which rm performed actions equivalent to the rmdir() or unlink() functions were removed. This puts the invocation of rm without arguments in the implementation's realm, where currently, coreutils is not consistent on what it returns: $ rm rm: missing operand Try `rm --help' for more information. $ echo $? # used improperly 1 $ rm -f $ echo $?# all (zero) calls to unlink succeeded 0 Both return statuses are defensible (neither is more intuitive). So is it worth bringing this up with the austin group? Is it worth changing rm to be consistent in its status regardless of options, or to keep the status quo of -f affecting the status? And if it is made consistent, I would lean towards a status of 0, so that constructs like rm -f `generate a list` succeed even if the list is empty. On the other hand, solaris rm also has the -f dichotomy, but returns 2 for syntax error if -f is not present. Furthermore, it is always possible for forced deletes to match POSIX requirements by using this idiom, since the file '' does not exist: rm -f `generate a list` '' But the same cannot be said for rm when -f is not in effect. Should this be mentioned in the autoconf portability documentation? Are there any systems out there where rm -f `` has non-zero status? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#160849: coreutils: bug report for GNU Core Utils
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/24/2005 1:58 AM:
Now, the help output for --reply looks like this:
--reply={yes,no,query} specify how to handle the prompt about an
existing destination file. Note that
--reply=no has an effect only when mv
would prompt without -i or equivalent, i.e.,
when a destination file exists and is not
writable, standard input is a terminal, and
no -f (or equivalent) option is specified
That wording is a bit awkward. How about this instead:
Note that --reply=no has an effect only when mv would prompt, either when
- -i is present, or for the combination of a destination file exists, is not
writable, standard input is a terminal, and -f (or equivalent) is not present
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCu/tp84KuGfSFAYARApSsAKCiKnapvQ/B7MTScZaiWEFDGJ2uiQCfUfwA
fU+r5LMJxtCYtnjA7hC5dX8=
=JiDj
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: base64 tool?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 6/25/2005 7:32 AM:
+++ NEWS 25 Jun 2005 13:28:40 -
@@ -167,6 +167,11 @@ GNU coreutils NEWS
stat -f's default output format has been changed to output this size as
well.
stat -f recognizes file systems of type XFS and JFS
+** New programs
+
+ base64 is a new tool that provide base64 encoding and decoding
+ functionality.
s/provide/provides/
+
* Major changes in release 5.3.0 (2005-01-08) [unstable]
Index: doc/coreutils.texi
===
@@ -1764,6 +1767,64 @@ address.
@exitstatus
[EMAIL PROTECTED] base64 invocation
[EMAIL PROTECTED] @command{base64}: Transform data into printable data.
+
[EMAIL PROTECTED] base64
[EMAIL PROTECTED] base64 encoding
+
[EMAIL PROTECTED] transform data read from standard input, or the
s/transform/transforms/
+string given as argument, into (or from) base64 encoded form. The
+base64 encoded form uses printable @acronym{ASCII} characters to
+represent binary data, see
[EMAIL PROTECTED]://ftp.rfc-editor.org/in-notes/rfc3548.txt, RFC 3548}.
+Synopses:
+
[EMAIL PROTECTED]
+base64 [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
+base64 --decode [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
[EMAIL PROTECTED] smallexample
+
+The base64 encoding expand data to roughly 133% of the original.
s/expand/expands/
+
+The program accepts the following options. Also see @ref{Common options}.
+
[EMAIL PROTECTED] @samp
+
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] -w
[EMAIL PROTECTED] --wrap
[EMAIL PROTECTED] wrap data
[EMAIL PROTECTED] column to wrap data after
+During encoding, wrap lines after @var{COLS} characters. This must be
+a positive number.
+
+If this option is not given at all, no line wrapping will be
+performed. If @var{COLS} is omitted, the default is 76.
Do we really want optional arguments to short options? POSIX tends to
prefer required arguments, so that -w76 and -w 76 behave the same. And if
base64 is ever adopted by a future version of POSIX, we might as well be
ready for it.
Also, I wonder if a default of 76 when --wrap is not specified or
specified without argument, and --wrap=0 as the special case to disable
wrapping, is more likely to be useful, since printable data usually
implies useful line wraps.
+
[EMAIL PROTECTED] -d
[EMAIL PROTECTED] --decode
[EMAIL PROTECTED] -d
[EMAIL PROTECTED] --decode
[EMAIL PROTECTED] Decode base64 data
[EMAIL PROTECTED] Base64 decoding
+Change the mode of operation, from the default of encoding data, to
+decoding data. Input is expected to be base64 encoded data, and the
+output will be the original data.
+
[EMAIL PROTECTED] -i
[EMAIL PROTECTED] --ignore-garbage
[EMAIL PROTECTED] -i
[EMAIL PROTECTED] --ignore-garbage
[EMAIL PROTECTED] Ignore garbage in base64 stream
+During decoding, ignore unrecognized characters (including newline),
+to permit distorted data to be decoded.
Is -i valid during encoding, or does your synopsis need to be updated to
show that -i can only accompany -d?
I didn't review the code itself, assuming that the bulk of it has already
been reviewed during the gnulib submission process.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCvXGK84KuGfSFAYARAkRhAKCqCx5FSqPC3TMLa77YSiXUHutBCgCfS8GL
d56ULkSHrCvqTe4w+bXA7Y4=
=9wKi
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls when acl() is busy [was: ls slow on top-level directory]
[bug-coreutils: posting this cygwin question upstream] On Jun 27 14:50, Will Parsons wrote: I notice that ls reports: /bin/ls: hiberfil.sys: No such file or directory /bin/ls: pagefile.sys: No such file or directory ls hitab completes to ls hiberfil.sys, and shows the same message. Could this have something to do with the slow response? No, that's entirely unrelated. In recent Cygwin snapshots the message from ls has changed to Device or resource busy and you get an ls output for these files. It's just an open() on exclusively locked files which fails in the above cases. Along these lines, we had a short discussion on the developers list and we're wondering if it's necessary that ls prints this error message at all. The message is generated after a stat() already succeeded and a follow up acl() call returns -1. To say it with Dave Korn's words: ISTM that ls has all the information it should need to DTRT - a successful call to stat(), a return value of -1 from acl() and (I would hope that) errno has EACCES(*) from the ERROR_SHARING_VIOLATION return should let it deduce 'the file exists but is locked', shouldn't it? (*) actually EBUSY. Eric? Hmm - murky waters here. It would be a simple one-line fix to coreutils/lib/acl.c to ignore EBUSY as a non-error, and POSIX has no requirements per se that a failure of acl() should imply a failure of ls(1). Should a busy file be conservatively treated as having an ACL (designated with '+' in the mode string) or left alone without one (designated with ' ' in the mode string) when cygwin is unable to query Windows without blocking for an undue length of time? Right now, I'm almost leaning for a third option, and displaying '?' or some other character to mean unable to determine, but that would be more work (the gnulib library file_has_acl already returns -1 on failure, 0 on no ACL, and 1 on ACL; perhaps make it return 2 on indeterminate). Should such a change be propagated to coreutils and gnulib, or left as a cygwin-local patch? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: base64 tool?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 6/27/2005 3:55 PM: -w is for encoding, -i for decoding. So they are orthogonal. I thought about making -w affect decoding to, so decoding would ignore (only) newlines after COLS. Could be fixed later on. I would have suggested this as well; I like the thought of -w during encoding adds newline at COL and at EOF, and -w during decoding ignores newline only at COL and EOF. As to your questions on other command line interfaces, I think base64 should at least behave as a filter: base64 file file.b64 base64 -d file.b64 file As for whether choosing on base64 abc whether abc is the filename containing text to be encoded, or the actual text to be encoded, I would lean towards filenames. Consider that your typical input is arbitrary length binary data, and passing that binary data directly as a command line argument is not a typical usage of a textual command line interface. Besides, if you can easily type the input as an ASCII argument, why do you need the 133% size penalty of encoding it? For a single file, it might make sense to support a -o/--output option to specify the name of the output file. Then base64 would be equivalent to base64 - -o -. I'm not sure of the best approach for scaling it to multiple input or output files, or if that is even necessary. Does the RFC permit, recommend, or discourage \r\n line endings in base64 encodings? Since the output is printable, you may want to consider carefully the decision between opening the coded file in text vs. binary modes on platforms where they are different. The decoded file must definitely be opened binary. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwUcK84KuGfSFAYARAhpGAKDX2l8op0WgsDowuuZ0KjJ+RtryKACggnl4 ZyV/YWqKcZopXDJ1sGs08yY= =vfDZ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls when acl() is busy [was: ls slow on top-level directory]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 6/28/2005 2:34 AM: Hmm - murky waters here. It would be a simple one-line fix to coreutils/lib/acl.c to ignore EBUSY as a non-error, and POSIX has no requirements per se that a failure of acl() should imply a failure of ls(1). Should a busy file be conservatively treated as having an ACL (designated with '+' in the mode string) or left alone without one (designated with ' ' in the mode string) when cygwin is unable to query Windows without blocking for an undue length of time? Right now, I'm almost leaning for a third option, and displaying '?' or some other character to mean unable to determine, but that I'd rather not do this. The output of ls is already complex enough and people having scripts munging ls output (well, just a thought...) would have a hard time to find the bug in their scripts. POSIX already requires the ' ' vs. '+' designator when a file has alternate access control (well, it only requires that the alternate access be listed as a printing character, but then recommends using '+' because it correctly implies that a file with ACLs may be more accessible to some other user than what was implied by the rest of the mode listing for the current user), and ls already implements this. Any script that tries to parse ls output is inherently non-portable to begin with. My only change would be adding '?' as the choice of printing character to indicate the indeteriminate nature of whether acls apply, and I don't think it violates POSIX or makes parsing ls output any harder than it already was. However, IMHO, ls should be changed to just print no error message, if file_has_acl() returns -1 and errno is set to EBUSY, and the file should simply be treated as a file with no ACL. That's the least intrusive way, IMHO. Certainly less intrusive, but also potentially misleading. The point of a new character is to make it obvious that ls was unable to determine if there are ACLs, rather than that the file has no alternate access. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwUyU84KuGfSFAYARAv1LAKCv6/91rsdc6BuhqTLbiAH98xFbDACglftF RG9tds5stI9j4Ak2XLPS3no= =sciN -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: base64 tool?
The RFC is fuzzy on the issue, but I want to discourage too lax treatment of encoded data. Lax treatment create opportunities for side channel attacks, and make implementations complex since they have to deal with various ill-formed input. So without --wrap, I definitely think the file should be opened as binary. But with wrap it is less clear. The RFC doesn't discuss what newline means. So I think we should open it as text. More thoughts appreciated. One thing to remember is that many RFCs expect \r\n (consider SMTP, HTTP, etc), so it might be nice to allow that even on Unix systems where only \n is normal! Maybe it is worth a command-line argument, where on encoding you can change the default line-ending (this requires opening in binary mode to guarantee that the OS doesn't change your wishes), and on decoding you can choose whether to be lax on any line-ending or robust to only allow one type of line-ending (again, this implies binary mode). But it's your call (esp. since you are the editor of RFC 3548 :). How about -l/--line-ending ENDING where ending is 'crlf', 'cr', 'lf', or 'any', and omitting -l or using -lany on encode defaults to lf, and omitting -l on decode defaults to any. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: switched coreutils to new regex implementation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 7/7/2005 6:32 PM:
I installed the following to sync coreutils from gnulib with respect
to regex. This is a big patch, so I won't enclose the stuff that's
identical to yesterday's gnulib patch.
gcc 3.4.4 emits these warnings on cygwin, when no -W flags are present.
In file included from regex.c:86:
regcomp.c: In function `init_dfa':
regcomp.c:921: warning: comparison is always true due to limited range of
data type
regcomp.c: In function `build_range_exp':
regcomp.c:2698: warning: comparison is always false due to limited range
of data type
regcomp.c:2698: warning: comparison is always false due to limited range
of data type
Cygwin defines WEOF to ((wint_t)-1), with sizeof(wchar_t) is 2 and
sizeof(wint_t) is 4. That means a wchar_t will never equal WEOF.
Hmm, when working on this patch, the Makefile does not have a dependency
of lib/libcoreutils.a on the changes to lib/regcomp.c. I also noticed
that I have both coreutils/lib/.deps/ and coreutils/lib/lib/.deps, if that
matters any. I'm not sure what the correct patch here would be, my
workaround to test the patch was just deleting lib/reg*.o.
2005-07-08 Eric Blake [EMAIL PROTECTED] (tiny change)
* regcomp.c (init_dfa, build_range_exp): Store __btowc value
in wint_t, not wchar_t.
Index: lib/regcomp.c
===
RCS file: /cvsroot/coreutils/coreutils/lib/regcomp.c,v
retrieving revision 1.1
diff -u -p -r1.1 regcomp.c
- --- lib/regcomp.c 8 Jul 2005 00:23:16 - 1.1
+++ lib/regcomp.c 8 Jul 2005 12:05:49 -
@@ -917,7 +917,7 @@ init_dfa (dfa, pat_len)
for (i = 0, ch = 0; i BITSET_UINTS; ++i)
for (j = 0; j UINT_BITS; ++j, ++ch)
{
- - wchar_t wch = __btowc (ch);
+ wint_t wch = __btowc (ch);
if (wch != WEOF)
dfa-sb_char[i] |= 1 j;
# ifndef _LIBC
@@ -2682,7 +2682,8 @@ build_range_exp (sbcset, start_elem, end
# ifdef RE_ENABLE_I18N
{
- -wchar_t wc, start_wc, end_wc;
+wchar_t wc;
+wint_t start_wc, end_wc;
wchar_t cmp_buf[6] = {L'\0', L'\0', L'\0', L'\0', L'\0', L'\0'};
start_ch = ((start_elem-type == SB_CHAR) ? start_elem-opr.ch
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCzmyG84KuGfSFAYARAn70AJ4ifNvPxJbMVyU3O5FbR7NK1mVCjQCcCWVv
TvzPe4CSeKJOfl3AqHW4MaQ=
=mPQW
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
more gcc warnings
A couple of porting problems caught by compiling with gcc -Wall on cygwin:
ls.c and stty.c use ioctl without including sys/ioctl.h, triggering a
warning about implicit declarations. Even worse, since ioctl is a varargs
function, this is undefined C (luckily, it compiles and links okay on cygwin).
I think the macros m4/jm-winsz[12].m4 are at fault here. Cygwin has
TIOCGWINSZ only in termios.h; while ioctl is only in sys/ioctl.h (or
term.h, which includes sys/ioctl.h), so both headers are needed
before ioctl (STDOUT_FILENO, TIOCGWINSZ, ws) will compile without
warning. This needs some autoconf magic (perhaps something that
defines IOCTL_IN_SYS_IOCTL), but I'm not sure of the best approach
for editing the existing m4 files.
id.c calls error (which ultimately gets to the printf family) with a format
%u for uid_t and gid_t. I really don't know of any portable way to print
an id_t, except that POSIX guarantees that they must be integer types
(with no further limitations, such as unsigned or not exceeding long). All
I could think of that won't truncate bits on some theoretical platform is
to cast to uintmax_t, which must work since they are integral.
2005-07-08 Eric Blake [EMAIL PROTECTED]
* src/id.c (print_user, print_group): Cast uid_t/gid_t to
uintmax_t before passing to printf family as %ju.
Index: src/id.c
===
RCS file: /cvsroot/coreutils/coreutils/src/id.c,v
retrieving revision 1.85
diff -u -r1.85 id.c
--- src/id.c30 May 2005 07:33:00 - 1.85
+++ src/id.c8 Jul 2005 20:09:17 -
@@ -202,7 +202,8 @@
pwd = getpwuid (uid);
if (pwd == NULL)
{
- error (0, 0, _(cannot find name for user ID %u), uid);
+ error (0, 0, _(cannot find name for user ID %ju),
+ (uintmax_t) uid);
ok = false;
}
}
@@ -225,7 +226,8 @@
grp = getgrgid (gid);
if (grp == NULL)
{
- error (0, 0, _(cannot find name for group ID %u), gid);
+ error (0, 0, _(cannot find name for group ID %ju),
+ (uintmax_t) gid);
ok = false;
}
}
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more gcc warnings
[EMAIL PROTECTED] (Eric Blake) writes: ls.c and stty.c use ioctl without including sys/ioctl.h, triggering a warning about implicit declarations. Even worse, since ioctl is a varargs function, this is undefined C (luckily, it compiles and links okay on cygwin). Thanks for reporting this. POSIX says that stropt.h declares ioctl, so let's try including that instead. POSIX spells it stropts.h (not stropt.h), and only on platforms that support STREAMS. Cygwin is not one of them, and has no stropts.h, so your patch will not help cygwin. Furthermore, cygwin's sys/ioctl.h is pretty wimpy - it declares JUST ioctl and 3 #defines WINDOWS_*. So this part of the patch needs a total rework to fix your misspelling and to still find a solution that supports cygwin. id.c calls error (which ultimately gets to the printf family) with a format %u for uid_t and gid_t. %lu should be good enough; id.c uses that elsewhere. If we run into hosts where uid_t and gid_t are wider than long int, then we can worry about it later. (Such hosts would not conform to pre-2001 POSIX.) This part looked fine. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more gcc warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 7/9/2005 1:40 AM: Does the following patch fix your problems with Cygwin? It hasn't hit anonymous CVS yet, but manual application of the patch from your email silenced gcc -Wall, so the problem has been addressed. Thanks for your help! Clearly the stropt.h - stropts.h fix was needed, so I installed that patch. If you still have problems with Cygwin please let us know. One more that I hadn't paid attention to - for systems with O_BINARY, the macro SET_BINARY was using setmode() without a prototype, and cksum.c calls SET_BINARY while using fileno() without a prototype. This fixes it for cygwin, but leaves other O_BINARY hosts (such as mingw) as is unless a maintainer for those ports chimes in. Should stdio.h be included in system.h, adding bulk to all the *.c files even though it only helps one, or should we redo this patch to just fix cksum.c to include stdio.h (perhaps conditioned on O_BINARY which implies the use of fileno)? There are a couple of other programs (such as expand.c) that only call fileno inside the SET_BINARY macro, but at least they already include stdio.h. On an unrelated question, I noticed that some files have copyright lines that don't match GNU coding standards. For example, ls.c has Copyright (C) 85, 88, 90, 91, 1995-2005 Free Software Foundation, Inc. http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices states Do not abbreviate the year list using a range; for instance, do not write `1996--1998'; instead, write `1996, 1997, 1998'. Do write each relevant year as a four-digit number. In the normal course of maintenance, you may come across copyright notices which omit the century, as in `1996, 97, 98'?change these to include the century. However, there is no need to systematically change the notice in every old file. 2005-07-09 Eric Blake [EMAIL PROTECTED] * src/system.h [O_BINARY __CYGWIN__]: Include actual headers for setmode and fileno. Index: src/system.h === RCS file: /cvsroot/coreutils/coreutils/src/system.h,v retrieving revision 1.132 diff -u -p -r1.132 system.h - --- src/system.h6 Jul 2005 09:34:09 - 1.132 +++ src/system.h9 Jul 2005 12:34:13 - @@ -217,7 +217,10 @@ initialize_exit_failure (int status) #endif #if O_BINARY - -# ifndef __DJGPP__ +# if defined __CYGWIN__ +# include io.h +# include stdio.h +# elif !defined __DJGPP__ # define setmode _setmode # define fileno(_fp) _fileno (_fp) # endif /* not DJGPP */ - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz8lM84KuGfSFAYARAvvlAJ9RX/Ndg1elQiDsoXfD7yiCI+alwgCdFN8Y FoGlwtOEx8VxFaRsCUeCux4= =UUqW -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
{base,dir}name // semantics
POSIX allows implementations to define the behavior of 'basename //' and 'dirname //'. Currently, both operations in coreutils output a single /, but this definition is worthless on platforms (like cygwin) where // is distinct from /. The intent, according to POSIX, is that 'cd $(dirname string) stat $(basename string)' access the same file as 'stat string' would do. I can look at preparing a patch to make both utilities output //, which would satisfy the intent of POSIX. First, I have one question - should this patch be made globally, or should it be limited to only systems that have a distinct //, leaving other platforms to continue having just a single slash returned? I would argue that cross-platform consistency is more important than reducing the output where // has no special semantics, so the change should probably be made for all platforms. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: {base,dir}name // semantics
[EMAIL PROTECTED] (Eric Blake) writes: should this patch be made globally, or should it be limited to only systems that have a distinct //, leaving other platforms to continue having just a single slash returned? Limit it to just those systems, please. I take it a simple autoconf test is in order (how about just testing to see if 'ls -di / //' produces 2 different inodes?), and that the results be used in the gnulib dirname module. I would argue that cross-platform consistency is more important But that cuts both ways: Solaris dirname // outputs /, and why should GNU/Linux dirname do anything differently? Let's not change this except on the poor platforms where leading // is special. Why doesn't gnulib use the platform's basename(3) and dirname(3), in libgen.h, if they are available? Doing so would allow the implementation to decide what behavior should be used. For that matter, it would fix cygwin's output, since cygwin's dirname(3) correctly returns // for //. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more gcc warnings
One more that I hadn't paid attention to - for systems with O_BINARY, the macro SET_BINARY was using setmode() without a prototype, Which include file declares setmode()? Where is this documented? I looked in the cygwin web site without much luck. cygwin's headers are poorly documented; I often resort to grepping /usr/include. setmode() is in io.h, along with get_osfhandle and a redundant declaration of access(). Should stdio.h be included in system.h I'd rather not. In fact, I'd rather system.h included less than it already does. should we redo this patch to just fix cksum.c to include stdio.h Sorry, I don't follow. cksum.c already includes stdio.h. Oh, it was because of the blind #define fileno _fileno, that I was getting the warning for an implicit definition. Cygwin properly declares fileno() in stdio.h, but does not declare _fileno. -# ifndef __DJGPP__ +# if defined __CYGWIN__ +# include io.h +# include stdio.h +# elif !defined __DJGPP__ What is io.h? Why does both it and stdio.h need to be included? stdio.h is not needed, but io.h is needed for setmode(). -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: {base,dir}name // semantics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 7/9/2005 2:25 PM: should this patch be made globally, or should it be limited to only systems that have a distinct //, leaving other platforms to continue having just a single slash returned? Limit it to just those systems, please. I originally thought the change would be limited to the gnulib dirname module, but I guess the change is worthy of documentation and NEWS. I also realized that on systems where 'basename //' returns '/', POSIX requires 'basename // /' to also return '/'. But on systems where 'basename //' returns '//', POSIX requires 'basename // /' to return '//', and this requires a patch to src/basename.c. Would it be better to patch remove_suffix() to return early if the name parameter ends in slash (in which case name must have been / or //), or to patch main() to not even call remove_suffix() in that case? Boy, I really need to get my copyright papers completed - I'll try pestering my employer again. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0m3W84KuGfSFAYARAtLNAJ9q7PPmEiABEVwKDCO5nFQviq7vzQCdGY/j MfvawlDZNdwYFTg/xdrq35w= =Inqk -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
text vs. binary [Re: more gcc warnings]
I've been putting off cleaning up this mess, but I found the time this
weekend to give it a start. I installed the following patch. It
avoids the use of setmode and io.h entirely, and it cleans up some
of the inconsistencies in the code (in some cases, they were bugs that
even infected the GNU/Linux version -- ouch!).
Thanks for starting this task.
Since I don't use DOS, someone with some expertise in that area will
have to double-check it.
I'm willing to check it on cygwin. This is a partial review, I will probably
have more comments as I get more time to actually comple and test
some of the changes. It would also be nice if someone could give anon
CVS a kick; it has been stuck since the 5th.
I would also like to compare your work to my email on the subject a
couple of months ago:
http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00136.html
I dislike all that isatty stuff -- is there some way that we could
easily remove it from the mainline sources, and put it in config.h or
somewhere we we don't have to see it? For example, can we replace this:
if (O_BINARY ! isatty (STDIN_FILENO))
freopen (NULL, rb, stdin);
with this:
if (O_BINARY)
freopen (NULL, rb, stdin);
Sounds like a good candidate for a gnulib module. Also, I've thought
more about fcntl(fd, F_SETFL, flags), where the nice gnulib behavior
would be:
neither O_BINARY nor O_TEXT: leave mode unchanged
O_BINARY: if not tty, force binary mode
O_TEXT: if not tty, force text mode
O_BINARY | O_TEXT: if not tty, swap mode
and have a wrapper on MS-DOS that defines freopen to not do anything
if the first argument is NULL, the second ends in b, and the third a
standard tty?
Since POSIX states that w+b and wb+ are synonyms, for example,
we should be a little more careful than just checking for ends in 'b'. Or
is there a coding style that states which of the two we should prefer?
Index: src/cat.c
@@ -553,9 +543,6 @@ main (int argc, char **argv)
{show-ends, no_argument, NULL, 'E'},
{show-tabs, no_argument, NULL, 'T'},
{show-all, no_argument, NULL, 'A'},
-#if O_BINARY
-{binary, no_argument, NULL, 'B'},
-#endif
I'd like to see a deprecation period rather than outright removal,
where -B is undocumented, and using it evokes a warning but
is otherwise a no-op (rather than a fatal unrecognized option).
Index: src/tac.c
Index: src/tee.c
@@ -140,7 +140,10 @@ tee (int nfiles, const char **files)
ssize_t bytes_read;
int i;
bool ok = true;
- const char *mode_string = (append ? a : w);
+ char const *mode_string =
+(O_BINARY
+ ? (append ? ab : wb)
+ : (append ? a : w));
Are there non-standard hosts out there that don't treat ab as
a synonym to a per POSIX, and if so, should we cater to them
with a gnulib module? It is much more readable to write this as:
char const *mode_string = (append ? ab : wb);
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df does not show all mounted disks
Hi, the command df on Windows does not show disk status, if a disk is mounted to a folder instead of a drive letter Best Regards, -- Christoph Are you using cygwin? If so, this question is best discussed there, on cygwinATcygwinDOTcom. Cygwin currently has a known design decision where getmntent does not mention drives mounted under directories (which is only possible on newer Windows versions, in the first place), because there is no quick way to make Windows gather that information without blocking for a LOOONG time while still being portable to older versions of Windows. If you are using some other port of coreutils to the Windows environment, ask the maintainers of that port. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
basename '' semantics
While working on my {base,dir}name patches for // handling, I
also spent some time editing tests/basename/basic to and creating
tests/dirname/basic. In the process, I came across the other
implementation-defined behavior, namely what basename ''
should return. POSIX allows either '' or '.'. (For dirname, POSIX
is explicit that the dirname of the empty string is '.').
One argument is that POSIX intends for cd $(dirname $name);
ls $(basename $name) to succeed for all valid $names, but since
$name='' is not a valid filename, it should cause a failure. The
counter-argument is that for compatibility, (at least for
/usr/xpg4/bin/basename on Solaris 8), older systems have already
been outputting '.', even though the dirname/basename sequence
creates a valid filename out of an invalid one, and since the POSIX
Examples section for basename states The basename utility is not
expected to make any judgements about the validity of string as a
pathname; it just follows the specified algorithm to produce a result
string.
Currently, coreutils returns ''. I don't want to change this unless
anyone else thinks it should be changed for compatibility. Comments?
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more gcc warnings
Paul Eggert eggert at CS.UCLA.EDU writes:
I dislike all that isatty stuff -- is there some way that we could
easily remove it from the mainline sources, and put it in config.h or
somewhere we we don't have to see it? For example, can we replace this:
if (O_BINARY ! isatty (STDIN_FILENO))
freopen (NULL, rb, stdin);
with this:
if (O_BINARY)
freopen (NULL, rb, stdin);
As it is, you will need a wrapper for freopen. At least Solaris 8 and cygwin
1.5.18 choke on the program below, dying with EFAULT instead of changing the
mode of stdin as POSIX requires. While I like your change stylistically, it
has broken coreutils CVS head on cygwin until we have a replacement freopen
that can handle a NULL filename when the platform won't.
#include stdio.h
#include errno.h
int main(void)
{
FILE* f = freopen (NULL, rb, stdin); /* Ensure that stdin is binary */
printf (file is %s, errno %d:%s\n, f ? good : null, errno,
strerror(errno));
return 0;
}
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.19s(0.132/4/2) 20050705 16:21:45 i686 unknown unknown
Cygwin
$ ./foo
file is null, errno 14:Bad address
$ uname -a
SunOS perth 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Blade-100 Solaris
$ ./foo
file is null, errno 14:Bad address
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more gcc warnings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 7/15/2005 4:10 PM:
For coreutils we don't need to worry about this. We can assume that
if freopen (NULL, ...) is being called, then the call is either
freopen (NULL, rb, stdin) or freopen (NULL, wb, stdout).
With that simplification, here goes a version of rpl_freopen that lets CVS
head work on cygwin. Of course, this is cygwin-specific; it would need
accompanying autoconf magic and #ifdef'ery to install it only on platforms
with O_BINARY and where freopen(NULL) doesn't work, without causing
compile errors on other platforms.
#include errno.h
#include fcntl.h
#include io.h
#include stdio.h
#include string.h
#include unistd.h
/* Like freopen, but when NAME is NULL, ensure that it is only used as
rpl_freopen (NULL, rb, stdin) or rpl_freopen (NULL, wb, stdout),
to force those streams to binary. Any other MODE or FILE for a NULL
NAME closes FILE and fails with EBADF. */
FILE *
rpl_freopen (const char *name, const char *mode, FILE *file)
{
int fd;
if (name)
return freopen (name, mode, file);
if (! mode)
{
errno = EINVAL;
return NULL;
}
fd = fileno (file);
if ((fd == STDIN_FILENO ! strcmp (mode, rb))
|| (fd == STDOUT_FILENO ! strcmp (mode, wb)))
{
if (! isatty (fd))
setmode (fd, O_BINARY);
return file;
}
fclose (file);
errno = EBADF;
return NULL;
}
Even if newlib (the provider of freopen() for both cygwin and mingw)
updates freopen() to actually implement file access changes where
possible, we still need to deal with the fact that a failure will
close the underlying file descriptor.
Is failure still possible under DOS, under the above assumptions? If
not, then let's not worry about it. Otherwise, is it OK if we simply
ignore the failure, and let later uses of the stream report an error?
I don't know whether DJGPP (the DOS port) uses newlib, or does something
else for freopen, or if it has bit-rotted in enough other places in
coreutils CVS to make it worth worrying about. If someone is actively
maintaining that port, they will let us know soon enough; otherwise I
don't think it is worth worrying about. The only problem I see with
ignoring the error is that freopen() is required to close its stream on
error, and that the documentation of fclose() states that operations on a
closed FILE* result in undefined behavior; but you are right that in
general, a closed stream will gracefully cause further errors that will be
detected by the existing code rather than crashing the system.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2Q8Q84KuGfSFAYARAo3YAJ95iMsv08tM6w+W+IyeMAwj3/01YACghLwJ
gkS3P7rCQfVpKC+cqHPbW5I=
=H7xC
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: New coreutil? realpath - retrieve canonicalized absolute path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sebastian Rasmussen on 7/18/2005 6:25 PM: Hi! Below is a patch (against coreutils-cvs) that implements a new coreutil of mine, realpath, that more or less wraps the libc call realpath(3). This is done in order to allow shell scripts or users to retrieve an absolute path given a relative path. What's wrong with the already-existing `readlink -f'? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC3HFa84KuGfSFAYARAlCpAJ9CqQS4b9N1ogZvBvOhRg5sJGbI2gCcDTx+ sDkUtOJcX6S5VEuW9v+7TEQ= =cO9c -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: banner
On my system there are two banner programs available. One is the SysV banner and the other is the BSD banner. The SysV prints large font text horizontally as for marking a screen or a printout. Cygwin's banner is a SysV knock-off, licensed under GPL (example best viewed in a fixed-width font): $ banner --help banner version 1.0 Prints a string enlarged as a banner on the screen. Usage: banner A string to print... General options -c, --char=X use character X -w, --width=80 set display width to 80 Help options -?, --help Show this help message --usageDisplay brief usage message --version Display version information --license Display licensing information This version works the same way as System V'S banner does: The banner text is displayed horizontally. $ banner foo bar blah XX XX X X X X X X X XXX XX X X X X X XX XXX X X X X X X XX XX X X X X X XX XXX X X X X X XX XXX X X XX X X XXXXXX X X X X X X X X X XX XXX X XX X XXX X X X XXXXX X X XXXXX X X XX X X XXX XXX $ Could you say a few words about why this program benefit from being included in coreutils? I can't speak for the original poster, but if an explanation for including banner is provided, coreutils should probably also improve it to add an option to select between horizontal (default, SysV style) and vertical (BSD style). One argument for inclusion might be that banner is a formatting utility, and coreutils already includes other formatting utilities, such as fmt(1), that are not standardized by POSIX but have appeared in traditional environments. Also, the original poster might get a lot further in the request if you posted the source code and documentation along with your request for inclusion. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: banner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Francky.Leyn AT telenet.be on 7/27/2005 9:37 AM: Could you say a few words about why this program benefit from being included in coreutils? On our system the core utils are installed for all platforms. Because banner isn't part of the core utils it is simply not installed, making I have to install it myself or ask a system manager to additionally install banner. The beauty of open source programs is that even if you don't have write privileges in /bin and /usr/bin, you can always create your own $HOME/bin, and compile (or find a precompiled version) and install banner there yourself, and update your $PATH to find it. In your case, that is probably faster than waiting for coreutils to decide whether to include such an app, then waiting for the next coreutils release. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC6EHA84KuGfSFAYARAsidAJ4hWCc0XpT1k9/3W/wYGplQ15WEAQCfXTEf Xo2pG6EARfqkQlWWvR9FpjI= =1TUC -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Using the command `date +%r` returns incorrect format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Martin Freebody on 8/2/2005 2:31 AM: BUG: Using the command `date +%r` returns incorrect format Version: 3.3.0 (using KDE 3.3.0, SuSE) Compiler: gcc version 3.3.4 (pre 3.3.5 20040809) OS: Linux (i686) release 2.6.8-24-smp Using the command `date +%r` should give me for example 2:39:00 PM but on my machine it returns 02:39:00. [time is set correctly as %R returns 14:39]. What is your locale? And what does `LC_ALL=C date +%r' print? This is a feature of strftime under locales. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC73L684KuGfSFAYARAs2QAJ9pFESQl0ztEXLC2cjy7eYYQfpakQCgkhhn 95oZvmlbky+g7Cw2HgE5+oU= =rNGx -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'expr' command not working with option *
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Saran on 8/11/2005 4:43 AM: To whom so ever it may concern.. Hi, I find that the expr command in my linux shell is not working for multiplying two arguments. please help me out how could i multiply two numbers in a shell and how could i use the command in my shell scripts.. when i type expr 2 * 3 it is giving syntax error. whereas if i type expr 2 + 3 it is giving me the correct result '5'. This is turning into a FAQ; although the FAQ page at http://www.gnu.org/software/coreutils/faq/coreutils-faq.html doesn't mention expr by name, it does mention problems with * as a shell metacharacter, which needs to be quoted. Try echo expr 2 * 3 to see what you are really doing. And compare that to echo expr 2 \* 3. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+0/g84KuGfSFAYARAuZRAJ9DooJLmd0kf2igT2kCDUUblsrkxwCeLy8J ns7moJ6uG53FvYoe0cUKGmU= =ni7b -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: random CVS file
Any reason that coreutils/lib/.gdb-history exists in CVS? I added it because I've found that sometimes the record provides useful clues (or reminders) for how to debug or investigate problems. It can also save typing, when you take advantage of gdb's readline history support. Is it causing trouble? No, I was just wondering why it was there, and you answered my question. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in cygwin's mkdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Chris Mumford on 8/22/2005 3:02 PM: I came across what I believe is an interesting bug. Let's say I have a file in a directory named foo.exe. If I run mkdir foo then it succeeds. If I then run mkdir -p foo then it fails. If I remove foo.exe then mkdir -p foo succeeds. The error message contains says foo exists but is not a directory. Bugs in the cygwin packaging of coreutils should be reported to cygwin AT cygwin.com. Setting the reply-to: accordingly. What you are seeing is caused by cygwin's auto-.exe extension behavior, and is not a bug in the upstream sources. The problem is that on cygwin, stat(2) on foo returns information for foo.exe if foo did not exist (a cygwin design decision that helps 99% of the time, since Windows does not like executables without extensions but Unix does; but it interferes in this case). The code path for `mkdir -p' uses stat(2) while the code path for regular `mkdir' does not. Now that you've reported it, the cygwin team will probably write a cygwin-specific patch to `mkdir -p' to ignore stat(2) if it appended .exe. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDCwsJ84KuGfSFAYARArlHAJ9wx80UqnFoQL/iiYMUUTOo/9vp+wCgo9Cf /sdnHtBseRG5sGtQ8+aEddQ= =0vDO -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#325205: please provide sha256sum, sha384sum and sha512sum
Can I ask you to take a look at the attached patch? It is not yet satisfactory (at least, it needs to be forwardported to the CVS version, as I worked against 5.2.1 because I wanted to install this ASAP on my Debian boxen), but maybe we can start from this to discuss what needs to be done. It implements sha224, sha256, sha384 and sha512. Would it make more sense to have a single sha utility that takes an argument of which algorithm to use, defaulting to the most secure, then the user can define wrappers to invoke a non-default algorithm? For example, 'sha --algorithm=sha224' or 'sha --224'? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Please, help me (ls find..coreutils)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to davy nedelec on 8/30/2005 6:16 AM: Hi, I'm using coreutils on Windows. Which distribution? If it is precompiled version from mingw or cygwin, you are better off checking with the distribution rather than here. Is there a way to display accentuated char (éàêë etc...)with ls and find. I tried to set LC_ALL=fr_FR, also tried to change the code page but it doesn't work. It may be that your terminal and shell display settings are at fault, rather than a coreutils/findutils limitation - are you sure you are set up to display 8-bit characters correctly? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFF0184KuGfSFAYARAm2NAJwKr3iTH1lMqRVlJ8AHM5DKjnXrigCgt6jc UeXWlGXuQoWP+CrZ+/JXyG0= =glVU -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
dircolors and default shell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Right now, if SHELL is not exported, and dircolors was not given a shell option, it refuses to output anything: dircolors: no SHELL environment variable, and no shell type option given Would it make more sense if dircolors tried to do a bit more sleuthing before giving up, such as trying getpwuid(getuid())-pw_shell, or examining files in /proc to reverse-engineer if the parent process of dircolors is a shell on systems that support procfs? Or is this too likely to be fraught with portability problems and potential wrong choices? One reason I ask is that by default, bash ensures that SHELL exists (either inherited from the environment, or populated as a shell variable), but does not put SHELL into the environment when populating the shell variable. So it can be rather confusing that 'echo $SHELL' prints something (the shell variable), but dircolors fails without -b because SHELL was not exported to the environment. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIDdV84KuGfSFAYARAsSsAJwJrzNLQ1XS02VFf0EcgH/nbd46UwCePMx4 VMg67tllleK+gBE0nzIJ1Tc= =/X7h -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Where can i get the design documentation for core utils?
Where can i get the design documentation for core utils? i.e basic algorithm for the utilities. Sometimes it is difficult to know what a particular code fragment is doing by just looking at the code itself. Unfortunately, you've stumbled across one of the weakness of open source. Many of the coreutils come from varied backgrounds, with varying levels of documentation, and there is no cohesive design document (besides reading the code itself). Contributions to improve the documentation and code comments are greatly appreciated. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I understand it, that is a deficiency in the Linux API rather than a bug in coreutils proper: Linux doesn't support the relevant sysinfo (Solaris-style) or sysctl (BSD-style) system calls. Perhaps you can report the problem to the Linux kernel folks. What about parsing /proc/cpuinfo, on machines that have that? (Cygwin falls into the same camp as linux, where this information is in /proc/cpuinfo, but not available from any easy system call.) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDJ5OH84KuGfSFAYARApHEAJ9rYI3q3EF8bVO/G5W7mDDvRrVUSwCfYUBL xTX4M5DVIUxlQbTNz+tfqf8= =18S5 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date not parsing full iso-8601
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 9/13/2005 4:16 PM:
OK, I installed the patch below. Comments welcome. In particular,
the new %:z, %::z, %:::z strftime formats are a bit weird-looking, but
I couldn't think of anything better.
All I could think of when the problem first came up was %Ez, since %E
specifies alternate format, but that doesn't really fit the three formats
you provided, so your choice seems great to me.
2005-09-13 Paul Eggert [EMAIL PROTECTED]
* NEWS: date has a new --rfc-3339 option, and the old --iso-8601
option is deprecated. date and ls also have new time format
specifiers %:z, %::z, %:::z.
* doc/coreutils.texi (Time conversion specifiers, Options for date):
Document date --rfc-3339 and new specifiers %:z, %::z, %:::z. Use
date and time consistently; the old version sometimes said time
and date. Fix a minor bug in the documentation for --rfc-2822:
it claimed day-of-month 10 had leading space, not leading zero.
Use a consistent format for terms like RFC.
* lib/strftime.c (my_strftime): Add support for %:z, %::z, %:::z.
Fix bug in formats like %2N.
* src/date.c (TIME_SPEC_DATE): No longer needs to be nonzero, so
remove the =1.
(TIME_SOEC_HOURS, TIME_SPEC_MINUTES): Must be at end now, so put
typo in the changelog
them there.
(time_spec_string, time_spec): Hours and minutes must be at
start now, so put them there.
(rfc_2822_format): Now a string constant, not a boolean. All uses
changed.
(iso_8601_format, rfc_format): Remove.
(RFC_3339_OPTION): New constant.
(long_options): Add --rfc-3339.
(usage): Add --rfc-3339. Don't mention --iso-8601.
Mention %:z, %::z, %:::z.
(main): Simplify calculation of 'format'; it was getting too hairy
to follow. Add --rfc-3339.
(show_date): Assume format arg is not NULL, which is the case
now. The default code is moved to 'main'. This simplifies things
and allows the default to be calculated just once.
* tests/misc/date: Add tests for --rfc-3339.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.308
diff -p -u -r1.308 NEWS
--- NEWS 10 Sep 2005 14:07:59 - 1.308
+++ NEWS 13 Sep 2005 21:59:04 -
@@ -182,6 +182,11 @@ GNU coreutils NEWS
cp and mv: the --reply=X option is deprecated
+ date accepts the new option --rfc-3339=TIMESPEC. The old --iso-8602 (-I)
+ option is deprecated; it still works, but new applications should avoid it.
+ date and ls's time formats now support new %:z, %::z, %:::z specifiers
+ for numeric time zone offsets like -07:00, -07:00:00, and -07.
What about du, pinky, pr, stat, and who, which also use a form of
strftime? And what about the FIXME in uptime to use strftime?
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
-Display the date using the @acronym{ISO} 8601 format, @samp{%Y-%m-%d}.
Now that -I is deprecated, should it print a warning to stderr? Or just
silently work for a couple of years until it is disabled?
+ --rfc-3339=TIMESPEC output date and time in RFC 3339 format.\n\
+TIMESPEC=`date', `seconds', or `ns' for\n\
+date and time to the indicated precision.\n\
TIMESPEC was optional for -I; should it be optional for rfc-3339 as well?
fputs (_(\
- %z numeric timezone (e.g., -0400)\n\
+ %z +hhmm numeric timezone (e.g., -0400)\n\
+ %:z +hh:mm numeric timezone (e.g., -04:00)\n\
+ %::z +hh:mm:ss numeric time zone (e.g., -04:00:00)\n\
+ %:::z numeric time zone with : to necessary precision (e.g., -04,
+05:30)\n\
I think the description of :, ::, and ::: would fit better in the optional
flags section below, rather than having to respace all the interpreted
%letter sequence listings because you listed them with %z.
Index: tests/misc/date
===
RCS file: /fetish/cu/tests/misc/date,v
retrieving revision 1.12
diff -p -u -r1.12 date
--- tests/misc/date 9 Sep 2005 07:22:27 - 1.12
+++ tests/misc/date 13 Sep 2005 21:59:08 -
@@ -166,19 +166,29 @@ my @Tests =
Where are the tests for %::z and %:::z?
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDJ5lQ84KuGfSFAYARAlZdAJ9w3pm2nR1ldE0Atan5DQARcJk8EwCfYRTu
jkHWqv3k8jz8WanPBYX6oRs=
=MbGV
-END PGP SIGNATURE
Re: Possible bug in uname command
That's been discussed, but it sounds like a can of worms. I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. But that will break scripts like mad... :( Since POSIX doesn't document -p or -i, they are already non-portable options. But you do have a point that just deleting the options may have far-reaching effects... -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Fwd: cat: invalid option -- h]
Just because two extreme cases support -h as a alias for --help, doesn't mean that it is a GNU convention. You still haven't given a good reason why -h should be a alias for --help. It is a common getopt option to trigger command line help, the most common I suggest. --help is the most common getoptlong option in GNU. Perhaps there is a GNU standard which covers this aspect of programs user-friendly-ness. The GNU coding standards ONLY require --help, and not -h, because of the fact that -h is ambiguous and some commands already have it standardized to mean something other than help. If you want help from a GNU program, --help is the only spelling that is guaranteed to work. We'll all have to remember to use --help long option if -h is not going to be consistent then. We can agree to differ on that if you cannot agree with my proposal. You are correct - coreutils is not going to add -h where it does not already exist, because --help already exists. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Fwd: cat: invalid option -- h]
My point is for consistency, it is unclear what the strategy is with -h in GNU tools, perhaps only a partial idea to use -h for help in some tools. -h has ended up being used for other purposes than help in GNU tools. The fact remains that -h is often used for help in GNU tools, but not in all cases. So I think GNU tools should be consistant, be that in having a -h option for help, or not using -h option for help in some GNU tools. There are some tools where POSIX requires that -h stand for something that is not --help, so consistency argues that `--help' be the choice for all GNU tools to support. If the strategy is actually to only have --help, perhaps GNU should define that somehwere, as obviously at present many GNU tools are supporting the -h option for help. Then you haven't read section 4.6 of the GNU Coding Standards, that do just that: http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html Also, section 4.7 mentions common long options, and their short option equivalents where appropriate, and neither --help nor --version are given a short option listing in the GCS. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: head -1 fails with _POSIX2_VERSION=200112
dixsept:~ _POSIX2_VERSION=200111 head -1 /dev/null dixsept:~ _POSIX2_VERSION=200112 head -1 /dev/null head: `-1' option is obsolete; use `-n 1' Try `head --help' for more information. zsh: exit 1 _POSIX2_VERSION=200112 head -1 /dev/null I do not think this is a good idea to fail on the old form, as it is still useful, at least with an interactive shell. This behavior has been changed in CVS coreutils. Whenever 5.3.1 is released, _POSIX2_VERSION=200112 head -1 will do what you are asking for. However, portable scripts cannot rely on this behavior, as it is no longer mandated by POSIX (and, as you note, released versions of coreutils reject it), so you may want to consider fixing your scripts to be portable anyway. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: head -1 fails with _POSIX2_VERSION=200112
The POSIX spec is a moving target. This has been fixed in the latest sources (available via cvs). There have been quite a few changes since 5.3.0 in January. Is it time to make a 5.3.1 release, so we can point people to a release instead of CVS? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df enhancment for removable media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juergen Weigert on 9/20/2005 2:54 PM: Wouldn't open() suffice? That would be simpler. I chose opendir(), because I am not sure if all systems allow open() on a directory node. Otherwise I'd also favour open(), it has no issue with getting a header file for dirent/direct, or whatever the directory structure may be called. POSIX requires open() to work on directories, and GNU find has been using open() and not opendir() for some time now (although with the recent switch in find to use gnulib's fts module, that will change in find 4.3.x.) The only bug that I am aware of that was reported to find where open(dir) failed was due to a cygwin bug which has since been fixed in cygwin. If, in fact, we do find a non-compliant system where open() fails on dirs, it might be better if that system were given a gnulib module that implemented a wrapper around open which calls stat then open/opendir as needed, rather than penalizing the majority of compliant systems. Sure. Is it sufficient to abondon copyright, Nope - FSF requires assignment of copyright, not abandonment. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMVFO84KuGfSFAYARArbWAJ4u5vf2mb2m41Xf4PXKUmrcl4vpkgCgiHLy XtODojf1rUFqFXGe6gw8bUA= =69ER -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in getaddrinfo module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 9/22/2005 11:14 PM: Thanks for reporting that. Aside from the missing netinet/in.h that you mentioned, I noticed a few other glitches. I installed the following fix into coreutils; does it fix things for you? If so, it should be propagated into gnulib. Works fine. Thanks for the quick fix. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNAAx84KuGfSFAYARAonzAJ9/OfsWJye2/j2kUCucGRzWXyGTtwCcDyyQ I9oCpvNXJQjGVFqUEZsJXRI= =4DXP -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[cc-ing bash-completion maintainer] First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a while ago, Bash now does a better job with file name completion. For example, given this: mkdir dir ln -s dir symlink If I type mv sym[TAB], where [TAB] stands for a tab character, the screen then looks like this: mv symlink If I type another [TAB] it then looks like this: mv symlink/ This assumes, of course, that you don't have 'set mark-symlinked-directories on' in your ~/.inputrc, at which point a single [TAB] completes the trailing slash. On the other hand, with the bash-completion package, it might make sense for programmable completion for mv, cp, and rm to omit the trailing slash in spite of the mark-symlinked-directories setting. The only argument against this is that there is no way to know whether the user really meant to move (or copy or delete) the symlink to a directory, vs. a file located in the directory, until they move on to the next word or hit Enter. This was the entire reason that mark-symlinked-directories exists in readline, and --strip-trailing-slashes exists as an option to mv and cp. On a related note, why don't rm and rmdir have a --strip-trailing-slashes option? so I'm given a signal from Bash that I have a symlink to a directory, and that it matters whether there's a trailing slash. Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Agreed - we should bring this up with the austin group. Something along the lines of this statement from rmdir(): If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail. ... [EINVAL] The path argument contains a last component that is dot. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_1 1) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. I agree with your logic here on rename(2) needing to fail on a trailing slash if it is also supposed to fail on a trailing dot. But that doesn't necessarily mean that mv(1) need to fail on a trailing slash or dot. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Oops - cygwin has a bug in this regards: $ mkdir dir $ rmdir dir/. $ echo $? 0 $ ls dir ls: dir: No such file or directory Is it worth patching coreutils rm and rmdir to work around buggy systems that don't follow this POSIX restriction on rmdir()? (Meanwhile, I will try to get cygwin fixed.) Should we update the coreutils testsuite? My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. You could probably convince me that your proposed approach of always rejecting an operation with a trailing slash is valid, as long as the error message gives a hint to the user on how to do what they wanted, and as long as --strip-trailing-slashes still worked. On the other hand, since 'mv symlink/ foo' invokes underspecified behavior in rename(2), maybe we can get away with deciding that mv(1) always behaves as --strip-trailing-slashes - is there anything in POSIX that would prohibit us from always stripping the trailing slash and acting on the symlink without an explicit option requesting that behavior? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
Yes, cygwin (but again, that goes back to the rmdir(2) bug
in cygwin that I have just reported to the cygwin maintainers):
$ mkdir a
$ ln -s a b
$ rmdir b/
$ ls -F a b
ls: a: No such file or directory
b@
Whereas on sane systems (for example, Solaris 8):
$ mkdir a
$ ln -s a b
$ rmdir b/
rmdir: directory b/: Path component not a directory
$ rmdir b/.
rmdir: directory b/.: Can't remove current directory or ..
By Paul's argument, both uses should have failed with
EINVAL, since POSIX requires resolving symlink/ as
symlink/., and requires rmdir(symlink/. to fail with
EINVAL. Solaris 8 returned ENOTDIR in the first case, so
it appears they stripped the trailing slash (and their error
message leaves something to be desired in accuracy in
the second case). But at least it reliably failed instead
of removing a. I don't have access to other systems to
see what other behaviors might exist.
Is it worth patching coreutils rm and rmdir to work around buggy
systems that don't follow this POSIX restriction on rmdir()? (Meanwhile,
I will try to get cygwin fixed.) Should we update the coreutils testsuite?
It depends a whole lot on how invasive or complicated the patch is.
Ideally, it wouldn't change anything in src/*.c at all.
If cygwin doesn't get patched, it sounds like a gnulib module
to replace rmdir() is all that would be needed. Something like
this untested snippet (it would need to be cleaned up for
corner cases like , /, ., but you get the picture):
int
rpl_rmdir(const char* name)
{
int len = strlen (name);
if (name[len - 1] == '/'
|| (name[len - 1] == '.'
(name[len - 2] == '/'
|| (name[len - 2] == '.' name[len - 3] == '/'
{
errno = EINVAL;
return -1;
}
return rmdir (name);
}
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
By a strict reading of
http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html,
'rm -R symlink/' should empty the referrant, then fail!
step 0: the command line does not end in .
step 1: symlink/ exists
step 2: 'symlink/' is of type directory ('symlink', on the other hand,
is of type symlink); this is the recursion, ending with the
referrant being emptied, and symlink and symlink/ still existing
step 3: 'symlink/' is a directory
step 4: call rmdir(symlink/), which should fail with EINVAL
But no implementation of rm(1) that I am aware of does this;
they all unlink symlink and call it quits, leaving the referrant
(and its contents) alone. We really do need to clean this up
with the austin group; surely they intended to document
historical behavior.
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: pkill
Most people use the builtin kill command of the shell, so you'll
have to change Bash as well as coreutils.
I wish that bash would remove all those builtins, or only use them if
a such a builtin doesn't exist on the system.
bash has the enable builtin which lets you disable builtins:
enable -n kill
Also, since kill is not a special builtin, you can always do one of:
alias kill=/bin/kill
kill() { /bin/kill $@ }
Remember, POSIX requires kill(1) to be a shell builtin, because
it must support job syntax (kill %1, for example), which cannot
be done with normal POSIX child process semantics. POSIX
also requires kill(1) to be an external program, invocable by
env, nice, xargs, etc. (it requires this of all non-special builtins),
with the documented effect that when invoked externally, job
syntax does not have to work.
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
