Re: mv feature request: -z swap files
TL Mieszkowski t...@ftfa.us wrote: I've needed to swap two filenames more than once, but no UNIX program I can find does it. The patch I've included works on two regular files, one regular file and a directory, but if you provide two directories or 1 directory first it trashes the first directory. I think this is due the vagaries of the rename function, but I can't understand why it happens. It says it can't copy a directory into itself, but the target doesn't even exist. There may also be issues across filesystems, since it uses the /tmp directory? Is there a way to do it without a /tmp? Is it possible to do it right, without just calling mv? Is this workable at all? Thank you for the patch, but this functionality does not belong in mv. However, a program that does that -- and does it robustly and efficiently -- would be a useful addition to coreutils. Note that it must be safe to run e.g., cd /tmp exch FILE1 FILE2, assuming the new tool is called exch. I don't want to dictate the language (or maybe I do ;-), but at least initially it should be a script, probably written in Perl. I'm considering maintaining a contrib/ directory in coreutils, and if someone already has such a script, I'd consider adding it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bugs in unexpand(1) version 6.10
Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What distribution are you using (I'm guessing Fedora 10). Distributions that patch coreutils really should modify the version string accordingly. if coreutils wants distros to do that, it should really facilitate things. the way gcc does it now with gcc-4.3+ is a pretty good standard: ./configure ... --with-pkgversion=some vendor/distro string ... Good idea. Patches welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] stdbuf work in progress
Pádraig Brady p...@draigbrady.com wrote:
I've started to work on the stdbuf util referenced in this thread:
http://lists.gnu.org/archive/html/bug-coreutils/2008-11/threads.html#00134
I've a few questions...
Hi Pádraig,
Thanks for writing/posting that.
The main one is should I introduce a dependency on libtool or use
something else. I'll be installing an unversioned shared lib (plugin)
My initial reaction is to avoid it.
on ELF systems, so I'm not sure the libtool dependency is desired?
Perhaps it's needed considering cygwin supports LD_PRELOAD?
We'll see.
The stdbuf util is built only on ELF systems. Is my check for such
systems in configure.ac appropriate?
Nice and minimal.
But I haven't researched it at all.
(Note libstdbuf.so is built unconditionally for the moment,
and is not installed. But the lib will be used if it's in the
same directory as the stdbuf util).
I'd rather avoid installing the .so alongside the other binaries.
I've added code to stdbuf to try and specify the full path
to the lib to LD_PRELOAD, rather than letting the dynamic
linker search for it. This is so as to remove the need to
add our lib install dir to the system search path, and
also simplifies testing as we can run stdbuf through the path
without having to setup LD_LIBRARY_PATH. Any gotchas with doing this?
I like not having to modify LD_LIBRARY_PATH.
We might want to substitute one directory name at build time,
so pre-installation tests work, and then to use a
different one in the installed binary.
I've currently split the util and shared lib into stdbuf.c
and libstdbuf.c. It might be better to just have a stdbuf.c
and build both binary and shared lib from that?
Yes, that sounds like it might be better -- but realize I've barely
glanced through the actual code.
Thanks.
Here's an incremental so that make syntax-check passes.
Additional syntax changes you'll need, eventually:
- filter thought indent so formatting (e.g. space-before-paren and
around arithmetic operators) is consistent
- convert the //-style comments to /*...*/
From 3ca87ad09f130e4d128e4a9681156eda8917d7d2 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 3 Feb 2009 10:07:37 +0100
Subject: [PATCH] mostly nits
* src/Makefile.am: don't make new rule the first (default)
* cfg.mk (sc_system_h_headers): Use VC_LIST_EXCEPT rather than
VC_LIST, so we can add an exception, if needed.
* .x-sc_system_h_headers: New file. Exempt libstdbuf.c.
* po/POTFILES.in:
* src/libstdbuf.c:
* src/stdbuf.c:
---
.x-sc_system_h_headers |3 +++
AUTHORS|1 +
cfg.mk |3 +--
po/POTFILES.in |1 +
src/Makefile.am|7 ---
src/libstdbuf.c|1 +
src/stdbuf.c | 20 ++--
7 files changed, 21 insertions(+), 15 deletions(-)
create mode 100644 .x-sc_system_h_headers
diff --git a/.x-sc_system_h_headers b/.x-sc_system_h_headers
new file mode 100644
index 000..14e020f
--- /dev/null
+++ b/.x-sc_system_h_headers
@@ -0,0 +1,3 @@
+^src/libstdbuf\.c$
+^src/system\.h$
+^src/copy\.h$
diff --git a/AUTHORS b/AUTHORS
index fa3c029..7095db0 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -76,6 +76,7 @@ sleep: Jim Meyering, Paul Eggert
sort: Mike Haertel, Paul Eggert
split: Torbjörn Granlund, Richard M. Stallman
stat: Michael Meskes
+stdbuf: Pádraig Brady
stty: David MacKenzie
su: David MacKenzie
sum: Kayvan Aghaiepour, David MacKenzie
diff --git a/cfg.mk b/cfg.mk
index 0e42042..2f356c2 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -151,8 +151,7 @@ sc_system_h_headers: .re-list
@if test -f $(srcdir)/src/system.h; then\
trap 'rc=$$?; rm -f .re-list; exit $$rc' 0 1 2 3 15; \
grep -nE -f .re-list \
- $$($(VC_LIST) src | \
-grep -Ev '((copy|system)\.h|parse-gram\.c)$$') \
+ $$($(VC_LIST_EXCEPT) | grep '^src/') \
{ echo '$(ME): the above are already included via system.h'\
12; exit 1; } || :;\
fi
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 6c291cc..921da4f 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -109,6 +109,7 @@ src/sleep.c
src/sort.c
src/split.c
src/stat.c
+src/stdbuf.c
src/stty.c
src/su.c
src/sum.c
diff --git a/src/Makefile.am b/src/Makefile.am
index ca12f9a..c0e7162 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -44,9 +44,6 @@ EXTRA_PROGRAMS = \
test timeout true truncate tty whoami yes \
base64
-libstdbuf.so: libstdbuf.c
- gcc -fPIC -shared -o libstdbuf.so libstdbuf.c
-
bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
noinst_PROGRAMS = setuidgid getlimits libstdbuf.so
@@ -170,6 +167,7 @@ du_LDADD += $(LIBICONV)
getlimits_LDADD += $(LIBICONV)
ptx_LDADD += $(LIBICONV)
split_LDADD += $(LIBICONV)
+stdbuf_LDADD += $(LIBICONV)
Re: sort b option in pos2 has strange effect
Pádraig Brady p...@draigbrady.com writes: Can someone at least confirm that we (should) interpret the a x input as having 2 fields, 'a' and ' x' ? A field comprises a maximal sequence of non-separating characters and, in the absence of option −t, any preceding field separator. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Difference in ln/ln -s semantics
How about for symlinks: When creating symbolic links, each TARGET path will be resolved relative to the parent directory of the symbolic link when it is accessed below the When creating hard links, each TARGET must exist. text. Is it too sutble that this may be a problem for relative paths? ln man page already contains a link to the symlink man page - but it's probably unlikely that someone using the tool is going to bother looking at the system call behind it. Vitali 2009/2/2 Eric Blake e...@byu.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/2/2009 6:06 AM: For semantic differences between ln and ln -s see the examples section. Thanks. Either would be good. Would you like to adjust doc/coreutils.texi accordingly? The coreutils.texi documentation is already lengthy: |A hard link is another name for an existing file; the link and the | original are indistinguishable. Technically speaking, they share the | same inode, and the inode contains all the information about a | file--indeed, it is not incorrect to say that the inode _is_ the file. | On all existing implementations, you cannot make a hard link to a | directory, and hard links cannot cross file system boundaries. (These | restrictions are not mandated by POSIX, however.) | |Symbolic links (symlinks for short), on the other hand, are a | special file type (which not all kernels support: System V release 3 | (and older) systems lack symlinks) in which the link file actually | refers to a different file, by name. When most operations (opening, | reading, writing, and so on) are passed the symbolic link file, the | kernel automatically dereferences the link and operates on the target | of the link. But some operations (e.g., removing) work on the link | file itself, rather than on its target. *Note Symbolic Links: | (libc)Symbolic Links. [By the way, POSIX 2008 mandates symlinks on all systems; about the only system worth porting to these days that still lacks symlink support is the non-POSIX mingw] If you change the man page (aka --help output), bear in mind that is should stay concise. It does point to the complete documentation in the info pages after all. The trick is coming up with a concise statement for the --help output which might help here. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpghttp://home.comcast.net/%7Eericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmG8T4ACgkQ84KuGfSFAYB//ACbBjudPs+E8lL43aNjMoFAuydV 8vIAn3XG2SrrSqSqzZ3W6ERvPJra4T7N =GWSF -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
Good afternoon What I have to say is a little bit... hard to believe. But I think I found a bug in the Shell-Command cp. The command goes into a endless loop when I do the following: 1) Mount a partition with the filesystem ext3 (/media/EXT3drive) 2) Mount a partition with the filesystem fat32 (/media/FAT32drive) 3) Generate a file on the ext3-System with a filesize 4GB 4) Try to copy this file from /media/EXT3drive to /media/FAT32drive with the following command: cp -urv /media/EXT3drive/4GBfile.img /media/FAT32drive/4GBfile.img 5) The file will be transfered until the filesize reached the 4GB limit. When the file has the maximum size that is possible on FAT32, it stop growing and cp is waiting forever to complet this file(wait about 48h - nothing happens). What cp should do: Check the filesystem on the target partition before the transfer begins and inform the user about any problems OR interrupt the transfer of this file and write a log/inform the user. Thanks for your attention Jeromy -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -a refuses to devolve file mode
cp -a refuses to devolve the file mode when I copy a certain file between two ext3 volumes whereas it does not report any error: cat syncit cp -a /home/./downloads/system/freebsd/bootstrap/etch/debootstrap /mnt/home-mirror/home/./downloads/system/freebsd/bootstrap/etch/debootstrap echo $? for i in /home /mnt/home-mirror/home; do ls -l $i/./downloads/system/freebsd/bootstrap/etch/debootstrap; done ./syncit 0 lrwxr-xr-x 1 root users 34 Jan 21 04:56 /home/./downloads/system/freebsd/bootstrap/etch/debootstrap - /compat/linux/usr/sbin/debootstrap lrwxrwxrwx 1 root users 34 Feb 3 17:06 /mnt/home-mirror/home/./downloads/system/freebsd/bootstrap/etch/debootstrap - /compat/linux/usr/sbin/debootstrap The file mode should be the same since cp has just successfully copied that file. I could not reproduce this behaviour in an artificial test setting. Please answer me as soon as possible to issue further tests since I do not know for how long this anomaly will hold. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
