Re: Suggested enhancement to du command - show last modified date.
William Brendling [EMAIL PROTECTED] wrote: ... Doesn't the standard ISO-8601 date format accomplish that, too? Quite likely. I will have to find out what the ISO-8601 format is. date already supports it: $ date --iso=s 2005-06-07T08:14:28+0200 ls does, too, via --time-style=STYLE. du's default format needn't include the time zone. It might be nice to have an option that makes it look at atime rather than mtime. Yes, I thought of that, but did not need it myself. Would you suggest a --last-accessed switch as well as --last-modified, or would it be better to have a modifier --use-time=atime|ctime|mtime? Since ls already has related options, it might make sense to do something similar. How about dropping the `use-' part of the option name and making it --time=...? `use time' or `time of last use' is a common description of `atime'. It's good to update the --help output and even better to update the primary documentation in the file doc/coreutils.texi. I have made an addition to the --help output to describe the --last-modified switch, but not the details of the date formats. I have not yet looked at trying to update the other documentation. You don't have to write much. Just say du's date format string is interpreted just like that of the `date' command. Writing ChangeLog entries describing your changes is helpful. OK. It may take me a while to do all this. No problem. Paperwork usually takes at least a couple weeks. Yes, please send me the forms. No promises. Coming right up. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
Bill, thanks for pointing out the bad example. I've added Bob's examples verbatim. Thanks, Bob. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutil? shuffle - randomize file contents
Frederik Eaton [EMAIL PROTECTED] wrote: Here is a preliminary patch for basic shuffling functionality in 'sort', with same-keys-sort-together behavior. It adds two options: -R to compare based on a hash of key, and --seed to specify salt for the hash. If --seed is not given then the default is to read from /dev/random or /dev/urandom. I still need to add support to configure.ac for some of the random device macros. Thanks. I haven't had time to give it serious consideration yet, but we should get started on the copyright-related paperwork. I'll send you the form separately. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
Thanks for clarifying that. What's misleading is when you say ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b I thought pointing to ./a would be an a in the current directory. Wouldn't it be nice: It seems that I fairly often run into situations where I wish ln had some additional functionality, although I can't say exactly what it should be. But for instance, after compiling a package yesterday with lots of executables, I just wanted to make links to all the executables and put them in my ~/bin. I decided to move them instead because I could do mv a b c d e f g ~/bin. To ln them, which I would prefer, I have to type ln longpathname/a longpathname/b ... . Now that I think about it, I could have defined a variable to shorten the path name, but there were something like 8 executables. Wouldn't it be nice if ln had an option to try to figure out the relative path from the target dir to the cwd (and could perhaps fall back to a hard path if necessary). Bill Bruno wrote: The examples in the man page say I can ln -s a b .. and get links in ../a and ../b to ./a and ./b Yes. Perhaps not the most useful of examples. Suggestions for documentation improvements are always welcome. but when I try it I get a link from ../a and ../b to themselves, which are useless circular links. The info docs say: ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b Symbolic links are purely linked by name value and nothing more. The names in the examples are a and b. Those are created in the directory .. and they do point to ./a and ./b. Not a useful example but still illustrative of what the command does. When the target is a directory the new files (symlinks are special files) created will be named the same as the source file names. Each one will hold the value of the source. Maybe it would be good to have some bad examples in the docs. Bad Example: # Create link ../a pointing to a in that directory. Not really useful # because it points to itself. ln -s a .. Better Example: # Change to the target before creating symlinks to avoid being confused. cd .. ln -s adir/a . Bad Example: # Hard coded paths don't move well. ln -s $(pwd)/a /some/dir/ Better Example: # Relative paths survive directory moves and also work across # networked filesystems. ln -s afile anotherfile ln -s ../adir/afile yetanotherfile I'm using tcsh in linux, uname -r : 2.4.21-20.EL Just fyi but neither of those two pieces of information matter. What might have mattered was the version of the 'ln' command. You can report it with the --version option. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
William J. Bruno wrote:
ln -s a b .. # creates links ../a and ../b pointing to ./a and
./b
I thought pointing to ./a would be an a in the current directory.
Nope. The value is used unchanged.
It seems that I fairly often run into situations where I wish ln had
some additional functionality, although I can't say exactly what
it should be. But for instance, after compiling a package yesterday
with lots of executables, I just wanted to make links to all the
executables and put them in my ~/bin. I decided to move them
instead because I could do mv a b c d e f g ~/bin. To ln them, which I
would prefer, I have to type ln longpathname/a longpathname/b ... .
Now that I think about it, I could have defined a variable to shorten
the path name, but there were something like 8 executables.
I would typically do a for loop on the command line in that case and
use shell variables as typing aides. In bash:
touch foo1 foo2 bar baz
cd ~/bin
for f in ~-/foo[12] ~-/{bar,baz}; do ln -s $f .; done
Of course use of ~- creates full path links and I want to avoid those
if possible or I can't access them over NFS and things like that. So
instead I would do this using shell file and directory expansion along
the way.
touch foo1 foo2 bar baz
cd ~/bin
for f in ../src/adir/foo[12] ../src/adir/{bar,baz}; do ln -s $f .; done
Wouldn't it be nice if ln had an option to try to figure out
the relative path from the target dir to the cwd (and could perhaps
fall back to a hard path if necessary).
I seem to recall this being available through some perl script. But
the actual example escapes me at the moment.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
