Re: making GNU ls -i (--inode) work around the linux readdir bug

> > EVERY application that invokes ls -i is effected. > > Please name one. magicmirror Which nobody uses. Try again; and this time a program that is in common use. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org

Re: getgid --help

getgid usage is invalid, mentions FILE while really it should be NAME: $ getgid --help Usage: getgid [OPTION]... [FILE]... Prints ID of given group name. --help display this help and exit --version output version information and exit Report bugs to . $ get

Re: installing

I am unable to install iTunes 8 with Wine. Half way through the setup "*the installer encountered errors before itunes could be configured" *any help?? Try using amarok or rythmbox. They are much nicer than iTunes, and they are free software! ___

Re: (no subject)

I think you posted to the wrong list... Your message seems to relate to the GNU Debugger. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: better figure out a paperless copyright assignment method

Wait a second, when making a Wikipedia editing contribution we just click on a box below some licence statement. Why can't you guys use that method? Because you don't get nice stickers that way. ___ Bug-coreutils mailing list Bug-coreutils@gnu

Re: Feature request: gzip/bzip support for split

I would like to propose a feature that allows to gzip/bzip on its way out during the split and I am also including the patch for the same. I think a better approach would be to add a --on-output-hook=PROGRAM command, then one can call any arbitrary command when split outputs a file. __

Re: Add redirection to "install" for package managers

I hope so. I'll creating that package, including a script named "install", and see if I don't need to patch GNU install. That'll work for many cases. (I plan to use the environment variable is REDIR_DESTDIR.) If it works EXCEPT that too many people invoke /usr/bin/install direc

Re: su command...

> Please, how can I execute the following idea: $ su gimp & > but really in bacground? I can not figure out what you want to do, but you might try=20 this : if [[ $(grep gimp /etc/passwd | cut -d':' -f1) == "gimp" ]]; then su - gimp; else su -; export DISPLAY=:0.0; gimp &; logout;

Re: Mac OS10 bug

say I want to sort on column 3, numericaly, reversed order: sort -nu +2 -3 file > files >From the Coreutils documentation, (coreutils) sort invocation: |On older systems, `sort' supports an obsolete origin-zero syntax | `+POS1 [-POS2]' for specifying sort keys. This obsolete behavior

Re: Core-utils 7.2; building only 'su'

However, I confirmed that "sudo make install prefix=$PWD/inst" did install su into $PWD/inst/bin. Eech, this is what DESTDIR is for... Works very well with coreutils. make install DESTDIR=$PWD/inst ___ Bug-coreutils mailing list Bug-coreutils@g

Re: Core-utils 7.2; building only 'su'

from the ./configure documentation it seems like --prefix=/foo would be preferred to destdir. Not at all! The correct method is to use DESTDIR, if you do: ./configure --prefix=$FOO --exec-prefix=$BAR and then do: make install prefix=$PWD/inst _ALL_ exec_prefix files (i.e. all arch. depen

Re: Core-utils 7.2; building only 'su'

Hmmm. Would it be worth changing autoconf to make './configure --help' state something like the following: | Some influential environment variables: | ... | DESTDIRleave unset during configure; allows installation to | specify a staging area different than t

Re: Core-utils 7.2; building only 'su'

>Hmmm. Would it be worth changing autoconf to make './configure >--help' state something like the following: > >| Some influential environment variables: >| ... >| DESTDIRleave unset during configure; allows installation to >| spec

Re: Core-utils 7.2; building only 'su'

>packages where DESTDIR doesn't work properly. But automake >already does such a good job at providing DESTDIR support >(especially if the user remembered to run 'make distcheck'), >that I think it would be nice if using AM_INIT_AUTOMAKE did >make the ./configure

Re: Core-utils 7.2; building only 'su'

> I tend to agree that INSTALL should either mention DESTDIR (and > probably also V, which now plays a role with new enough > automake), or at least point to the GNU Coding Standards and the > Automake manual overview of the GNU build system. Does anyone > want to beat me to a patch

Re: Core-utils 7.2; building only 'su'

>>Hmmm. Would it be worth changing autoconf to make './configure >>--help' state something like the following: >> >>| Some influential environment variables: >>| ... >>| DESTDIRleave unset during configure; allows installation

Re: Core-utils 7.2; building only 'su'

> So for maximum portability you should support this in your > package, too. BTW, why do you state that overriding just $prefix > would be "almost always wrong"? In the w32 arena, overriding $prefix at `make install' time is unilaterally *correct*. Why can your staging area not mi

Re: [bug-inetutils] Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...

doc/fdl.texi is removed below If I'm understanding correctly, removing fdl.texi seems wrong to me. I'm supposing it's created dynamically from a copy in gnulib or somewhere now? But the license can't be updated merely by changing that file. The @copying block has to be update

Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...

After the patch I installed to inetutils [1], I think actually the only problem is that the gnulib 'fdl' module is a moving target. That doesn't really work, as Karl explained, since the main manual needs to be updated manually whenever there is a FDL version update in gnulib. Right

Re: tail +n does not work under Linux?

I have just noticed that 'tail +n' does not seem to work under Linux. Please don't call the GNU system for Linux, Linux is a important part of the system, but it is not the name of it. Linux is the kernel of the GNU system, when people call the whole system for Linux they give none of the p

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

+Depending on the package, the default directory layout chosen during +...@command{configure} can be altered during subsequent execution of +...@command{make}. A `make install FOO=VAL' should never alter anything in the build directory. The problem is if you pass --bindir=/foo to confi

Re: improve INSTALL contents

>+Depending on the package, the default directory layout chosen during >+...@command{configure} can be altered during subsequent execution of >+...@command{make}. > > A `make install FOO=VAL' should never alter anything in the build > directory. The problem is if y

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

How about this? I took into account Ralf's comments as well. In addition, if you use an unusual directory layout you can give options like @option{--bind...@var{dir}} to specify different values for particular kinds of files. Run @samp{configure --help} for a list of the directories

Re: improve INSTALL contents

Indeed - I want to be very clear in INSTALL that there are some basics that pretty much any client of this file provide (make, make install), and some options that nice packages provide but which may fail if someone borrowed this file but does follow everything checked by automake's

Re: improve INSTALL contents

>In addition, if you use an unusual directory layout you can give >options like @option{--bind...@var{dir}} to specify different >values for particular kinds of files. Run @samp{configure --help} >for a list of the directories you can set and what kinds of files >

Re: improve INSTALL contents

can you please also read, and follow ? I'm sure you must have missed it because I failed to spam it to three mailing lists. But your repetitions are just as boring as those from everyone else. And get bug-coreutils a

Re: printf "%c" behavious

I deleted it and added /usr/local/bin to my path. `printf "%c" 65' is still outputting '6' but `/usr/local/bin/printf "%c" 65' is giving 'A'. Any idea what's going wrong? Shell builtin probobly. If you are using GNU bash then the following will disable the printf builtin: enable -n prin

Re: Missing "tail" feature, bug?

>From the documentation for coreutils: ,[ (coreutils)tail invocation ] |On older systems, `tail' supports an obsolete option | `-COUNTOPTIONS', which is recognized only if it is specified first. | COUNT is a decimal number optionally followed by a size letter (`b', | `k', `m') as in `-c',

Re: POSIX misunderstanding

Note that "head" is a historic BSD tool. You broke a shitload of stuff when you took out the old BSD options. Nobody took them out, they are still there. Read the info pages for details. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://li

Re: su strange behaviour

___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: su strange behaviour

And check that you (the OP) have debugging symbols in su and/or libc, otherwise anything that gdb will say will be useles. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: su strange behaviour

Hmm... I'm quite sure that I didn't send this email. Unless I somehow managed todo that by accident... ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: cp -upv copies even when not newer

Works for me. [EMAIL PROTECTED]:/tmp$ echo ooo>c [EMAIL PROTECTED]:/tmp$ cp -upv c e `c' -> `e' [EMAIL PROTECTED]:/tmp$ test c -nt e;echo $? #is it newer? No. 1 [EMAIL PROTECTED]:/tmp$ cp -upv c e [EMAIL PROTECTED]:/tmp$ cp --version cp (coreutils) 5.2.1 cp (coreutils) 5.0.91 You might wish t

Re: ~ ! a bug..., more like a lack of a feature?

'ls', by default for root, comes '-A' - which ignores '.' and 'chgrp' should also have a similar '-A' flag available to it. You probobly have some aliases set when you are root, check with the command `alias' if you are using bash.

Re: coreutils: Test manpage improvements (-e, -w and -x)

Maybe the manpage could be ammended (see the patch attached). If the manpage is reviewed maybe it's worth reviewing also Debian bug #230957 (I can't understand why it is tagged 'wontfix' by the Debian maintainer) Because man pages are generated from the --help output and the offical d

Re: coreutils: Test manpage improvements (-e, -w and -x)

$ touch test $ ln -s test testl $ test -e testl && echo true true $ rm test rm: remove regular empty file `test'? y $ test -e testl && echo true You are probobly still using the test builtin from bash. Both `test' and `[' are builtins in bash by default. ___

weird echo behaviour...

Could someone explain the following behaviour for me? Because I sure do not understand it. [EMAIL PROTECTED]:/tmp/foo$ touch 1 2 3 4 5 [EMAIL PROTECTED]:/tmp/foo$ foo=`ls` [EMAIL PROTECTED]:/tmp/foo$ /bin/echo $foo 1 2 3 4 5 [EMAIL PROTECTED]:/tmp/foo$ /bin/echo "$foo" 1 2 3 4 5 [EMAIL PROTECTED]

Re: weird echo behaviour...

> Could someone explain the following behaviour for me? Because I > sure do not understand it. > > [EMAIL PROTECTED]:/tmp/foo$ touch 1 2 3 4 5 > [EMAIL PROTECTED]:/tmp/foo$ foo=`ls` > [EMAIL PROTECTED]:/tmp/foo$ /bin/echo $foo > 1 2 3 4 5 > [EMAIL PROTECTED]:/tmp/foo$ /bin/

Re: weird echo behaviour...

> Could someone explain the following behaviour for me? Because I > sure do not understand it. You will be slapping your forehead as soon as you realize what is happening. Yeah... Makes all kind of sense in the world now, but I still don't like it.

Re: weird echo behaviour...

It's useful in cases like "ls | grep", etc. Yeah, but I still don't like it. :) It should figure out automagicly what I want using AI or something.. Anyway, back to my cave. Thanks for all the replies... Happy hacking! ___ Bug-coreutils mailing

install

The following is a bit annoying when you want to install something as a normal user, but just "ignore" any set permissions/owners/groups. /usr/bin/install -c -o root -m 4755 mail.local /home/update/ams/gnu-tools/gnu/stow/hurd//libexec/mail.local /usr/bin/install: cannot change ownership of `/hom

Re: install

> Would it be possible to add some kind of a --ignore=TYPE (with > short option -i), where TYPE is either `group', `mode', `owner' > option that would ignore EPERM or such and just continue if it > was specifed? I think it would be better that if one is not root that the EPERM er

Re: [patch] 5.2.1: prevent compiler warning

The fold_text() function doesn't ever return anything and its return code is never checked. There is no fold_text() function in coreutils 5.2.1. [EMAIL PROTECTED]:~/coreutils-5.2.1$ grep -r fold_text * [EMAIL PROTECTED]:~/coreutils-5.2.1$ ___

Re: missing --help information for command "rmdir"

i have noticed there is no -option character for "ignore-fail-on-non-empty", Because of the simple reason that there is no such short option for --ignore-fail-on-non-empty. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mai

Re: uniq: exit status not documented enough

P.S. just for fun let's compare the clarity of Info vs. Man: Compare it all you want, the info pages are the canonical place for information when it comes to coreutils. Want info about a utility, you look it up in the info pages not the man pages.

Re: uniq: exit status not documented enough

I think Dan was saying that the man page is clearer in this case. Changing the info page to match the man page could be an improvement. Then Dan should say so instead of giving a long lecture about totally irrelevant stuff as he usually does. And I happen to like the wording in the manua

Re: touch - cannot use options "backward"

However, I tried several version of touch (coreutils): 4.5.3, 4.5.8, 5.0, 5.2.1 and this option is not available. GNU touch has never had this (--backward) option. Or is there another program to change the time stamp of a file (like 1 hour backward). touch -m -t MMDDhhmm FILE Where

Re: man pages must still work minimally

Thanks for reporting those. I've done this: * src/ls.c (usage): Clarify description of --author. I don't know how you clarified it, but if you did what I think you did, i.e. added something like "print it only in when doing a long listing". Then it would be a good idea to do the

Re: man pages must still work minimally

help2man, not in the output listing. Infact, I would prefer to have this used consistently in all GNU projects. 2004-11-19 Alfred M. Szmidt <[EMAIL PROTECTED]> * src/ls.c (usage): Clarified description of --no-group (-G), --human-readable (-h), --inode (-i), --size (-s), --

Re: man pages must still work minimally

I applied your patch -- or tried. Two hunks didn't apply, but I managed :) Whoopsie... >--- src/ls.c5 Oct 2004 17:38:15 - 1.366 >+++ src/ls.c19 Nov 2004 19:29:55 - 1.367 >@@ -4057,7 +4057,7 @@ Mandatory arguments to long options are >

help2man and indented help text

Hi, help2man produces spurious blank newlines if you indented the --help text like this: --sort=WORDextension -X, none -U, size -S, time -t, version -v status -c, time -t, atime -u, access -u, use -u The output that he

[EMAIL PROTECTED]: help2man and indented help text]

Bah, screwed up in writting the email addy to the help2man bug mailing list. --- Start of forwarded message --- From: "Alfred M. Szmidt" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Fri, 19 Nov 2004 23:09:07 +0100 Cc: Subject: help2man and indent

Re: [PATCH][RFC] New 'true' program

(The 10-byte implementation is left to the reader. :-) But that is so big! Think what I could use 10 bytes for! /home/update/ams $ ./true; echo $? 0 /home/update/ams $ ls -l true -rwxr-xr-x 1 ams 134 0 Nov 20 18:59 true Implementation details are also left to the reader. __

Re: [PATCH][RFC] New 'true' program

$ ls -l true -rwxr-xr-x 1 prowlands users 0 Nov 20 12:59 true $ ./true; echo $? 0 (The implementation is left to the reader. :-) Bah, someone beat me to it... :-) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/m

Re: [EMAIL PROTECTED]: help2man and indented help text]

Guessing which lines are continuations and which are new lines is darned tricky, and the rules help2man uses are intended to deal with the majority of cases. I don't know how help2man does this in detail, but wouldn't it work just to see if the next line as a option (either, -s or --short

Re: [PATCH][RFC] New 'true' program

The current true program is an amazing-bloated thing. As you have seem from the small dicussion, that even your 3.2k is "bloated". Point is that 13k is nothing, now if you really need to save 13k on a system then you should first of all not use the GNU C library; and secondly, compile everythi

Re: [PATCH][RFC] New 'true' program

So can you guys please consider this cleanup then? It would break international support. May one ask why you are so concerned about saving a few bytes? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreu

Re: [PATCH][RFC] New 'true' program

> > So can you guys please consider this cleanup then? > > > >It would break international support. I can't see how, as the binary ignores parameters like --help, even though it is present in the man page. No it doesn't, ~ $ /bin/true --help Usage: /bin/true [ignored command li

Re: [PATCH][RFC] New 'true' program

>May one ask why you are so concerned about saving a few bytes? I think it is an outrage that a simple task like returning a code indicating success has to take more than a few bytes. Well, that doesn't answer the question but shifts it. Why do you consider it an "outrage" that it takes

Re: [PATCH][RFC] New 'true' program

More than just a few bytes: $ /usr/bin/time true 0.01user 0.00system 0:00.02elapsed 41%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (134major+35minor)pagefaults 0swaps I think that this is valid for the ``false'' program too: $ /usr/bin/time false Command exited wi

Re: [EMAIL PROTECTED]: help2man and indented help text]

>I don't know how help2man does this in detail, but wouldn't it >work just to see if the next line as a option (either, -s or >--short). And assume that if doesn't, that it is a continuation? >This would solve all cases I think. Perhaps, although it's been my experience that muckin

Re: robust chdir and openat (works with names longer than PATH_MAX)

> # error "use this module only if your system defines PATH_MAX" That would be the Hurd, no? Can't we just fall back to the system chdir in this case? I was about to ask the exact same thing! Our implementation of chdir() doesn't have a PATH_MAX limit (see [libc]/sysdeps/mach/hurd/chdi

Re: robust chdir and openat (works with names longer than PATH_MAX)

Sighs, I shouldn't get up this early and write emails. What I _really_ meant to write was the following. Is this code only used if the real chdir() implementation is incapable of handling infintly long directory names? By using a autoconf check or whatever? Happy hacking! __

Re: robust chdir and openat (works with names longer than PATH_MAX)

> Is this code only used if the real chdir() implementation is > incapable of handling infintly long directory names? By using a > autoconf check or whatever? Yes, that's the current status of the code, and none of the proposed changes should affect this. Of course there could

Re: Suggestion for dd -- Why didn't anyone think of this before.

It seems really odd to me that in 30 years, no one ever thought to add the ability to give feedback about it's progress to the user. Odder is that you haven't read the manual! :-) ,[ (coreutils)dd invocation ] |Note that sending a `SIGUSR1' signal to a running `dd' process makes | i

Re: Debian's at(1) is so bad, what does GNU use?

Constructive me says: Debian's at(1) is so bad, one can't even do $ at next year parse error. Last token seen: year Garbled time $ at now + 12 months #Sigh. Must use instead. No wonder. Not genuine GNU parts. Say, Stallman to the rescue. What do those cool GNU people use? Don

Re: Debian's at(1) is so bad, what does GNU use?

A> nohup sh -c "(sleep 100h; move-my-toes)" & Yeah, never rebooted where you live. Does at survive a reboot? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils

coreutils CVS

Anyone know what is wrong with the CVS? null:~/coreutils$ cvs up -Pd Invalid CVSROOT (2) cvs update: invalid data from cvs server null:~/coreutils$ CVSROOT is ":ext:[EMAIL PROTECTED]:/cvsroot/coreutils"... Cheers. ___ Bug-coreutils mailing list [EMA

Re: coreutils CVS

> Anyone know what is wrong with the CVS? Not I. I just asked savannah-hackers what's going wrong. Thanks, I might note for the record that the only repo that isn't working for me from savannah is the coreutils one, all other usual projects that I hack on work. Cheers. _

Re: CoreUtils broken links

I've been trying to look for CoreUtils mailing list archives, but the link provided at http://www.gnu.org/software/coreutils is broken. I'm trying to access http://mail.gnu.org, and even this address seems to be offline. It got changed to http://lists.gnu.org, but the mind boggles why

coreutils CVS repo...

I'm getting the following when trying to create a diff in the coreutils cvs. Other projects at Savannah work dandy. ~/coreutils $ cvs diff cannot create_adm_p /tmp/cvs-serv25051/config Permission denied ~/coreutils $ ___ Bug-coreutils mailing list Bu

uptime on GNU

The following makes uptime work on GNU, we don't use the same means as GNU/Linux or *BSD to get the boot time. It was tested by Michael Banck. Happy new year. ChangeLog 2004-12-29 Alfred M. Szmidt <[EMAIL PROTECTED]> * src/uptime.c [HAVE_PS_CONTEXT_CREATE &&

[EMAIL PROTECTED]: uptime on GNU]

Ping pong poo... --- Start of forwarded message --- From: "Alfred M. Szmidt" <[EMAIL PROTECTED]> To: bug-coreutils@gnu.org, [EMAIL PROTECTED] Date: Wed, 29 Dec 2004 20:28:18 +0100 Subject: uptime on GNU The following makes uptime work on GNU, we don't use the same

Re: [EMAIL PROTECTED]: uptime on GNU]

I'll look into all the stuff you commented on and fix it in a while, don't have a GNU/Hurd box at hand. The proposed patch sometimes generates a result that is off by 1. If the boot time is 1.9 seconds after the epoch, and the current time is 2.1 seconds after the epoch, it will report an

Re: [EMAIL PROTECTED]: uptime on GNU]

I didn't test it (I don't have easy access to GNU/Hurd). It was just code inspection. Oh. Obviously it's a minor point, but you might as well get it "right". Obviously. :-) Thanks for the comments. ___ Bug-coreutils mailing list Bug-coreut

Re: A new utility: trv

It's called "trv" (for "traverse"). It will recursively traverse a directory tree and execute in each subdirectory the command passed as an argument. How is this different from say, for x in `find . -type d`; do (cd $x; COMMAND); done This might be a bit longer, but it is more flexible.

Re: A new utility: trv

Once findutils does the deacent thing... cat >> $HOME/.env

Re: A new utility: trv

Why the this long rant? Sorry, I really don't see what point you are trying to make by comparing `trv' against starting/stoping services, using stat for listing files, that anything vim can do can be done in vi (which is false by the way). Nor do I see any merrit in the long expose about Unix phi

Re: about error messages of GNU coreutils

Although I am not good at writing English, I e-mailed to you with courage :-) Your English is quite good. I attempted to compile coreutils. Then some lines of error messages are generated when I invoked ./configure. I attached the error log to this mail. There aren't any errors i

Re: -e test for file exists problem with dangling symlinks

-e file exists test fails if file is a dangling symlink, this to me does not seem like the correct behavior, the test should not follow the symlink (lstat'ed instead of stat'ed). The file (whatever the symlink is pointing to, and a file isn't a symlink) doesn't exist, so it should fail.

Re: ls -l --no-total

> Did I mention ls should have a --no-total option > to remove those annoying > total 1120 > without needing to pipe to a filter. Another possibility would be to output the `total' to stderr. The horror, why do people come up with these silly ideas? `total N' is not a error me

Re: ls -l --no-total

I've seen other programs printing only informative messages to stderr. Depends on what you call a "informative message", a warning should go to stderr. Normal output should go to stdout. `total ' is normal output, hence it should go to stdout. I know this behavior is standardized b

Re: date zh_TW.Big5 +%P

Better ask a real Chinese. Or better yet: Send a patch. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [Patch] Adding examples to the man pages

I think it would be better to add this where it belongs, in the info pages. That is the proper place to document this. The format for man pages is very bad to provide proper documentation to users in either case. ___ Bug-coreutils mailing list Bug-cor

Re: [Patch] Adding examples to the man pages

This is unfortunate, since coreutils contains tools which are heavily used by beginners as well as expert users. Beginners should read the info pages to begin with, since they contain more useful information then the man pages. So I fail to see how this argument holds water. :) I, for

Re: [Patch] Adding examples to the man pages

Info pages, powerful as they are, are almost exclusively GNU only. Man is the universal source of documentation for Unix like systems and it seems to me that the basics should be in man pages And this has absolutley no relevance, GNU's Not Unix, and Info pages are where documentation is p

Re: new coreutil? shuffle - randomize file contents

If you intened on making shuffle part of coreutils someday, then you could use the GNU womb repository on Savannah. You'd need to get proper papers form [EMAIL PROTECTED] though, and if you add code that was written by someone else we'd need papers from them too. But this would make putting shuff

Re: sudo apt-get install sun-j2rel.5

[EMAIL PROTECTED]:/home/rage # sudo apt-get install sun-j2rel.5 Reading package lists... Done Building dependency tree... Done E: Couldn't find package sun-j2rel.5 please reply if you know what I'm doing wrong You are trying to install non-free software. That is what is wrong.

Re: GNU install error

should ask your system administrator to take a look at it, since we do not know what is going exactly. >From ams Tue Aug 16 20:52:07 +0200 2005 From: "Alfred M. Szmidt" <[EMAIL PROTECTED]> To: Matthew Rich <[EMAIL PROTECTED]> CC: gnu-misc-discuss@gnu.org In-reply-to: <[EMA

Re: Where can i get the design documentation for core utils?

Unfortunately, you've stumbled across one of the weakness of open source. And unfortunatly you are crediting GNU coreutils to a movement that doesn't care about freedom. Design documents have nothing to do with free software, or open source for that matter. For GNU coreutils there is littl

Re: Where can i get the design documentation for core utils?

Unfortunately, the source code does not always have the internal documentation it should, and can be quite hard to follow. An excellent example of this is sort.c. Bad example, sort.c is trivial to follow and understand. The problem is not confined to coreutils. GNU libc, for instanc

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 op

Re: Possible bug in uname command

Since POSIX doesn't document -p or -i, they are already non-portable options. GNU Coreutils isn't POSIX Coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

> > 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

Re: Possible bug in uname command

>I don't think it will break scripts because legacy operating >systems don't support those options either. ^^ > If you consider GNU a legacy operating system, sure. Recall, GNU > coreutils is for GNU, not non-GNU systems. Not

Re: Possible bug in uname command

If Hurd implements the interface to enable 'uname -p' then that would certainly be a good thing in general. A win-win. But if it does not then already at this time 'uname -p' is not really useful to there. But that isn't a good reason to make the option produce a error. If you ar

Re: Possible bug in uname command

I like the fix. Though, changing the behaviour of `uname -a' just cause some people have rebelled against it outputing `unknown' in some places is quite silly; why not add such support to Linux and have it output something useful! Thanks Paul. ___ Bug

Re: [Fwd: cat: invalid option -- h]

I've not received a reply, could you confirm if you received my email please? Sure. Can cat -h be added as an alias of --help please? Why? Seems utterly useless for --help, rather save it for something that is potentionally useful. Cheers.

Re: [Fwd: cat: invalid option -- h]

[EMAIL PROTECTED] removed from CC] So why should cat be any different? 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. -h is quite uncommon as a alias for --h

Re: [Fwd: cat: invalid option -- h]

We'll all have to remember to use --help long option if -h is not going to be consistent then. Your argument really doesn't make any sense. -h is used for other things than getting a usage message in GNU tools, making -h a alias for --help in some GNU tools would only lead to utter confus

  1   2   3   >