Our thought about fixing the problem of cp --recursive
hi, Jim We decide to take your suggestion after researching fts and remove.c. Use fts to perform the source-tree traversal and traverse the destination tree by keeping two file descriptors. Thank you for your suggestion. :-) But we find some problems during our research. There are some coreutils library functions that may fail due to ENAMETOOLONG. Such as same_name utimecmp futimens utimens gl_futimens euidaccess savedir copy_acl set_acl qset_acl areadlink_with_size Functions that call the above function(s) may fail, so we decide to rewrite these coreutils library functions. Do you have any better suggestions? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Our thought about fixing the problem of cp --recursive
Cai Xianchao <[EMAIL PROTECTED]> wrote: > hi, Jim > > We decide to take your suggestion after researching fts and remove.c. > Use fts to perform the source-tree traversal and traverse the destination > tree by keeping two file descriptors. > Thank you for your suggestion. :-) > > But we find some problems during our research. There are some coreutils > library functions that may fail due to ENAMETOOLONG. Such as > same_name > utimecmp > futimens > utimens > gl_futimens > euidaccess > savedir > copy_acl > set_acl > qset_acl > areadlink_with_size > > Functions that call the above function(s) may fail, so we decide to > rewrite these coreutils library functions. Do you have any better > suggestions? Yes, you will need file-descriptor-based versions of those functions. For example, a same_name_at function would take two file descriptors and two entry names and perform operations very similar to those of the existing same_name function. The only difference is that all operations in the new function would use file descriptor *at functions, like fstatat, rather than lstat or stat, and fpathconf rather than pathconf. In fact, since the directory file descriptors will be provided, the new function won't have to perform any *stat* call at all. A properly written version of cp will avoid even forming the full name of each copied file. The only reason to form a full name is to present it in a diagnostic or in an interactive prompt. Bear in mind that many of those functions are gnulib modules. For each module you write, you will want to create the following new files, e.g., gl/modules/same-name-at gl/m4/same-name-at.m4 gl/lib/same-name-at.c gl/lib/same-name-at.h Then add same-name-at to the list of modules in coreutils' bootstrap.conf. There is already a futimensat function in recent Linux kernels, and it should be easy to add emulation support for it in gnulib. Note that euidaccess is problematic. Since you've been reading remove.c, you may have already noticed the long comment in the write_protected_non_symlink function. copy.c will need something similar. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: argve0, psfool
On Tuesday 25 December 2007, Andreas Schwab wrote:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
> > Brian Dessent <[EMAIL PROTECTED]> writes:
> >> "Daniel C. Bastos" wrote:
> >>> I always miss these two programs on every system I meet. argv0 is very
> >>> handy when dealing with programs that care about argv[0] and psfool is
> >>> essential when giving out passwords through the command line. I figure
> >>> these two should be in coreutils.
> >>
> >> perl -e 'exec { "real" } "fake", "arg1", "arg2"'
> >
> > bash -c 'exec -a "$0" "$@"' real fake arg1 arg2
>
> That should of course be:
>
> bash -c 'exec -a "$0" "$@"' fake real arg1 arg2
perhaps a "contrib" subdir with small scripts like this ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Command line parsing with genparse
FWIW, GNU tar uses argp for parsing arguments. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
tail -n N
man tail -c, --bytes=N output the last N bytes -n, --lines=N output the last N lines, instead of the last 10 say -c N, --bytes=N etc. just like grep(1). P.S., For compatibility `tail' also supports an obsolete usage `tail -COUNT[bcl][f] [FILE]', which is recognized only if it does not conflict with the usage described above. COUNT is an optional decimal number optionally followed by a size letter (`b', `c', `l') to mean Mention it also doesn't work if more than one file is given: $ tail -1 aa aaa tail: invalid option -- 1 Try `tail --help' for more information. $ tail -1 aa Bla $ Version: Changelog here on Debian goes up to 2006-06-12 Paul Eggert <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
