[EMAIL PROTECTED] wrote:
> On (info "(coreutils)File type tests", and test(1) man page, we see
> `-t FD'
>True if FD is a file descriptor that is associated with a terminal.
>
> Well please mention what happens if FD is omitted:
bash's "help test" explains this, if you know where to look
I got this failure from "make check" with coreutils 7.0. It looks
like a bug in the test, rather than in df itself. df is complaining
about not being able to access a mount point which has a FUSE
filesystem mounted on it.
=
GNU coreutils 7.0: tests/
"G. Vamsee Krishna" <[EMAIL PROTECTED]> wrote:
> So, isn't `printf "%c" 65' supposed to print 'A' instead of '6'?
I agree that that would be the more useful behavior, but SUSv3 seems
to require "6".
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTE
"G. Vamsee Krishna" <[EMAIL PROTECTED]> wrote:
> What I still didn't get it, is this a bug or a feature left intentionally?
It's intentional.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Markus Kuhn <[EMAIL PROTECTED]> wrote:
> $ uname -d
> SuSE Linux Professional 9.1 (DVD 32-bit)
> $ uname -dv
> SuSE
> $ uname -dp
> Linux Professional
> $ uname -dr
> 9.1
> $ uname -da
> DVD 32-bit
Should the meaning of -v/-p/-r/-a depend on the presence of -d, or
should these get new option names
Albert Cahalan <[EMAIL PROTECTED]> wrote:
> begin quote ---
> XBD ERN 16 Utilities that have extensions violating the Utility Syntax
> Guidelines Accept as marked.
>
> It was agreed that an interpretation be made , that the standard
> is clear and no change is required.
Felix von Leitner <[EMAIL PROTECTED]> wrote:
> Proposed fix (in paste.c):
>
> static char dummy_closed;
> static char dummy_endlist;
> #define CLOSED ((FILE*)&dummy_closed)
> #define ENDLIST ((FILE*)&dummy_endlist)
The C standard allows undefined behavior for such casts, since the
dummy va
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thomas Habets <[EMAIL PROTECTED]> writes:
>
>>> sort: Add an ordering option -R that causes 'sort' to sort according
>>> to a random permutation of the correct sort order.
>>
>> This means that two different files, that happen to sort to the same outpu
Paul Eggert <[EMAIL PROTECTED]> wrote:
> You are asking for a program that randomly permutes its input. Then
> let's design another program to do that, and not get bogged down
> with how its features work together with "sort"'s existing zoo of
> options.
That might be the best thing: create a new
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
> 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 PROT
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>Command substitution works by the shell creating a pipe to capture
>the output; when ls sees that it is writing to a pipe, it defaults
>to -1 instead of -C.
>
> Urgh, thanks for the explanation. I suppose this can't be changed
> right? Ca
"Duane Cox" <[EMAIL PROTECTED]> wrote:
> Apparently chown also grabs .. all the way up to /home and changes
> that ownership as well as any users in /home
>
>
> [EMAIL PROTECTED]:/home/dcox# chown -Rv dcox.users .*
The pattern ".*" matches "..", so chown sees ".." as one of its
arguments and duti
Suresh Krishnan <[EMAIL PROTECTED]> wrote:
> I needed a command to normalize a pathname and I did not find any.
Does "readlink -f" do what you want?
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-cor
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>> 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.
I think Dan was saying that the man page is clearer in this case.
Changing
Paul Eggert <[EMAIL PROTECTED]> wrote:
> "tail -n COUNT" already uses the sign of the count for something
> different, so it would be confusing if "head" used the sign in the way
> that you suggest.
It might be a better parallel if "head -n -1" (or some other spelling)
wrote all but the last N lin
Mike Miller <[EMAIL PROTECTED]> wrote:
> The 'ls' command has many great features/options but case insensitivity is
> not one of them.
Where would you want to have case insensitivity? If you're thinking
of pathname generation from wildcards, that's handled by the shell,
not ls. This might be w
Dan Bolser <[EMAIL PROTECTED]> wrote:
> Cheers, I can't see any diff with tail -n 3 and tail -n -3 though...
"tail -n +3" is the one that's different.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-cor
Brendan Byrd/SineSwiper <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~/tmp/a> mv -s b/f .
> mv: `b/f': can make relative symbolic links only in current directory
Does "mv -s b/f b/.." work? If not, I'd think that case (where the
destination starts with all the same path components as the source
Brendan Byrd/SineSwiper <[EMAIL PROTECTED]> wrote:
> I think my main point is that this is not a serious limitation, or at
> least one that was never brought up until now. It's apparently been in
> the copy.c code for eons. There must be some reason for this limitation
> to be put in place
Oh
"Bryce Nesbitt (mailing list account)" <[EMAIL PROTECTED]> wrote:
> The "wc" command always seems to place leading spaces on all results,
It doesn't for me, with 5.2.1. Upgrade?
paul
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists
Jim Meyering <[EMAIL PROTECTED]> wrote:
> A string of zero digits is interpreted as `0'.
That sounds to me like it's talking about "00". Maybe "A string
of no digits"? Or "A line that ends or has has nondigit characters
where the number would be"?
paul
__
Paul Eggert <[EMAIL PROTECTED]> wrote:
> /* Bound on length of the string representing an integer value or type T.
>Subtract 1 for the sign bit if t is signed; log10 (2.0) < 146/485;
>add 1 for integer division truncation; add 1 more for a minus sign
>if needed. */
> #define INT_STRLEN
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Technically, yes, but that would prohibit applying that macro
> to variables, which is useful. Currently there are uses like
> that in the coreutils.
Ah - well, it's easy enough to factor, so you'd have to specify the
signedness explicitly for variables,
Dan Jacobson <[EMAIL PROTECTED]> wrote:
> No way to hand echo or /bin/echo a NULL.
For /bin/echo, that's because execve() uses null-terminated strings.
For bash's builtin echo, it could be done, but then it would be
inconsistent with external commands, which might be surprising.
paul
_
Mathieu Roy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Bob Proulx) a tapoté :
>> find . -print0 | xargs -r0 md5sum
>
> Right.
> But -r is easier.
The find command is easier to implement, and is just as easy to use if
you save it in a shell script.
#!/bin/sh -e
find ${1+"$@"} -print0 | xargs
On my system, the "nobody" user does not have a usable shell.
make check-TESTS
make[3]: Entering directory `/fs/data/mount/home/prj/src/spf/coreutils-4.5.9/tests/rm'
out exp differ: char 1, line 1
1c1
< su: /nil/nobody/shell: No such file or directory
---
> rm: cannot remove `a/b': Operation not
Jim Meyering <[EMAIL PROTECTED]> wrote:
> For the time being, I've made the following change:
>
> * tests/rm/fail-2eperm: Rather than simply using the first non-root
> user name, make sure that the selected user name has a usable shell.
But then you might find a real user account; that
Jim Meyering <[EMAIL PROTECTED]> wrote:
> I've just added this to TODO:
Great, thanks.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Phil Tanguay <[EMAIL PROTECTED]> wrote:
> I would like to submit for inclusion a small modification I made to
> the sleep program to allow sleep to pause for a random # of seconds,
> up to the # of seconds specified (or whatever time suffix was
> specified).
Why not: perl -e 'sleep(42*rand())'
p
false --help exits 0. false --version exits 1. I think false --help
should be changed, but certainly one of them should be.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Paul Jarc wrote:
>> false --help exits 0. false --version exits 1. I think false --help
>> should be changed, but certainly one of them should be.
>
> Hmm... I think all commands with --version should exit 0 for
> consistency.
I
Tsuyoshi Takada <[EMAIL PROTECTED]> wrote:
> ---
> a
> b
> delimiter
> c
> d
> delimiter
> e
> f
> ---
>
> to
>
> ---
> a b
> c d
> e f
> ---
You can do this with sed. Append each input line (with trailing
spaces, if you
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I love poking sticks into hornets' nests, so I can't resist mentioning
> that coreutils "true" sometimes returns false:
>
>$ ./true --version >&-
>./true: write error: Bad file number
>$ echo $?
>1
Hm - I can't reproduce this.
$ `which true
I wrote:
> glibc 2.3.2, if that makes a diffference.
It does: apparently, glibc 2.3.2 opens stdin, stdout, and stderr to
/dev/null if they're not already open. So by the time main() is
called, they will always be open.
paul
___
Bug-coreutils mailing
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Zach J. Elko wrote:
>> Granted, it executes that command as the user who ran su, I think it
>> would be better to just display an error message and then take the
>> excess bytes and throw them into /dev/null.
>
> The problem is how do you know when to stop re
Jens Elkner <[EMAIL PROTECTED]> wrote:
> unfortunately env is not POSIX, or to be more specific, not "The Open Group
> Base Specifications Issue 6 IEEE Std 1003.1, 2003 Edition" compliant on Linux.
> (see http://www.unix-systems.org/version3/iso_std.html )
>
> E.g.: filename.env
> #!/usr/bin/env -i
[EMAIL PROTECTED] (Paul Jarc) wrote:
> Jens Elkner <[EMAIL PROTECTED]> wrote:
>> Last but not least - why not
>> ...
>> static char *pointer2null = NULL;
>> ...
>> main() {
>> ...
>> if (ignore_environment)
>>
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Found in the exec man page on some systems:
>
> The initial line of a script file must begin with #! as the first two
> bytes, followed by zero or more spaces, followed by interpreter or
> interpreter argument, as in:
>
>#! inter
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Paul Jarc wrote:
>> Bob Proulx wrote:
>>> One or more spaces or tabs must separate interpreter and argument.
>>
>> Note that this is a doc bug; the space was never required.
>
> I agree that there was never a need fo
Dan Jacobson <[EMAIL PROTECTED]> wrote:
> Paul> With a single argument, test only tells you whether that arguments is
> Paul> empty. You want "test -t 0" (or 1 or 2).
>
> $ man test
>-t [FD]
> file descriptor FD (stdout by default) is opened on a terminal
> I.e. argument opti
Paul Eggert <[EMAIL PROTECTED]> wrote:
> POSIX long ago decided that FD is not optional with test -t. GNU
> 'test' conforms to POSIX in this respect.
bash's does, but coreutils' doesn't.
$ /bin/test -t > /dev/null ; echo $?
1
$ /bin/test --version
test (GNU coreutils) 5.0
Written by FIXME: ksb a
[EMAIL PROTECTED] (Bob Proulx) wrote:
>% stty raw
>% cat -u > fi
This may not work; the interactive shell may reset the tty modes after
each command, so the first stty would bhave no effect. This might
work:
% sh -c 'stty raw; cat -u > fi; stty sane'
> Either Stevens with Advanced Progra
Jesse Kornblum <[EMAIL PROTECTED]> wrote:
> Although the one-liner you demonstrated should work quite nicely,
> it's a lot to type on a regular basis.
Why not script it?
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailma
Bobby L Morris <[EMAIL PROTECTED]> wrote:
> Since the Perl sort function works correctly, is it possible that
> the problem could be in the way the sort command interacts
> with the LANG environment instead of the LANG environment
> itself ? With Perl I did not have to change LANG;
Perl's sort
Dan Jacobson <[EMAIL PROTECTED]> wrote:
> aren't argument limits old fashioned?
Every kernel (note, that's kernel, not ls) has them.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Dan Jacobson <[EMAIL PROTECTED]> wrote:
>>> aren't argument limits old fashioned?
>
> P> Every kernel (note, that's kernel, not ls) has them.
>
> hmmm, maybe error messages could steer the blame better,
The error message is also not ls's doing; it's the shell's.
paul
__
"Daniel de la Cruz" <[EMAIL PROTECTED]> wrote:
> rm --.xxx
>
> cant delete names that start with 2 dashes '-'
http://www.gnu.org/software/fileutils/doc/faq/core-utils-faq.html#How%20do%20I%20remove%20files%20that%20start%20with%20a%20'-'%20such%20as%20'-i'%3f>
paul
Jim Meyering <[EMAIL PROTECTED]> wrote:
> * tests/rm/fail-2eperm: Now that we have setuidgid, use it in
> place of the kludge in this test.
How about also using this to run the non-root-only tests when "make
check" runs as root?
BTW, why are there three different ways of reporting thi
Jim Meyering <[EMAIL PROTECTED]> wrote:
> * tests/rm/fail-2eperm: Now that we have setuidgid, use it in
> place of the kludge in this test.
Thanks. I think NON_ROOT_USERNAME should be mentioned in README too.
(ATM, README still has a now-out-of-date note that setuidgid ought to
be use
Daniel Russell <[EMAIL PROTECTED]> wrote:
> Using wc in scripts is annoying because of the fact that this:
>
> wc -l/m/c FILENAME
>
> prints this:
>
> NUMBER FILENAME
Removing the filename is easy enough:
wc -l < FILENAME
paul
___
Bug-coreut
"Kevin Klein.Osowski" <[EMAIL PROTECTED]> wrote:
> The ls -a command does not give an alphabetically sorted list of
> files, sorted by file name.
...
> I am using ls version 4.5.3 with glibc-2.3.2 on x86 redhat 9.
This sounds like a locale issue. What does "locale" say? What do you
get if you ru
Nicolas Bonifas <[EMAIL PROTECTED]> wrote:
> Hello, I think I've found a bug in cat: when I type 'cat true' (when
> I'm in the directory of the 'true' binary, /bin/ on my computer), my
> terminal becomes unreadable (normal characters are printed as
> control characters).
It's not a bug. cat is do
vatbier <[EMAIL PROTECTED]> wrote:
> NO, the output of "cat /var/lock/subsys/dm" is written over by the
> prompt of my shell (dm has a number like 1114)
> [EMAIL PROTECTED] home]$ cat /var/lock/subsys/dm
> [EMAIL PROTECTED] home]$
> My system is Mandrake Linux 9.1 with bash v2.05b
> Is it possi
<[EMAIL PROTECTED]> wrote:
> I think a safer and more intuitive way would be that when wildcards
> are used, mv would treat the file* expression as single source
> argument and tell the user to provide a destination.
mv has no way of knowing whether wildcards were used. The shell
expands wildcard
Jim Meyering <[EMAIL PROTECTED]> wrote:
> And if you build the GNU coreutils on a system that conforms to
> POSIX 1003.1-2001, then you'll find that the above all fail, e.g. like this:
>
> $ head -1
> head: `-1' option is obsolete; use `-n 1'
> Try `head --help' for more information.
> [Exi
Jim Meyering <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) wrote:
>> Given the significant number of complaints about this behavior, I
>> think it would make sense to reject -1, etc., only if $POSIXLY_CORRECT
>> is set.
...
> These changes are in a di
Scott Baker <[EMAIL PROTECTED]> wrote:
> I'd really like a simple way to JUST list all the directories in a
> given directory.
$ ls -d */
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Jim Meyering <[EMAIL PROTECTED]> wrote:
> But bear in mind that the vast majority of users don't have a
> problem because they use these tools via a distribution mechanism
> (.rpm, .deb) that arranges not to install programs like hostname
> that can cause trouble.
Still, it would be nice to make l
[EMAIL PROTECTED] (Bob Proulx) wrote:
> So I really can't see how someone can call it a bug that they don't
> exist. I can only see that someone would rather use the net-tools
> version with all of the bells and whistles instead of basic
> functionality of the BSD compatible versions.
Right. But
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Why can't GNU/Hurd use the code from the net-tools package?
Maybe it could. But net-tools also provides commands such as ifconfig
and route, which are Linux-specific (in terms of their implementation
details). I don't know whether their hostname command is
Spencer Garrett <[EMAIL PROTECTED]> wrote:
> The sort utility in RH 9.0 ignores case by default,
http://www.gnu.org/software/fileutils/doc/faq/core-utils-faq.html#Sort%20does%20not%20sort%20in%20normal%20order!>
paul
___
Bug-coreutils mailing list
[E
Jim Meyering <[EMAIL PROTECTED]> wrote:
> After 10 years of being merely `obsolescent', head -N has finally
> been officially declared to be `obsolete'.
This doesn't respond to Ari's argument, though: given that GNU
utilities already go beyond the standard's requirements by supporting
long options
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Going beyond the requirements (in an explicitly-permitted fashion)
> is not the same as violating the standard. Making head accept
> +n/-n would violate the standard.
Where is the explicit permission for long options?
Here is the explicit permission for
Paul Eggert <[EMAIL PROTECTED]> wrote:
> It's up to your the coreutils installer (typically a software
> distribution maintainer) to specify the default value for
> _POSIX2_VERSION.
How is that controlled, exactly? I think it ought to be documented in
README.
> So the compatibility problems that
Paul Eggert <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> If the choice is somehow truly under the control of the coreutils
>> installer, then I would be happier.
>
> It's clearly under their control now.
It's clearly under the contr
Herve Autret <[EMAIL PROTECTED]> wrote:
> But it is not possible to run Python -O by this way, because env seems
> to look for a "Python -O" executable.
>
> Don't you think that this is clearly a bug in env ?
No. This is a limitation of the kernel. Different kernels behave
differently; some will
I wrote:
> I'd say your best option would be to file a Python feature request, so
> that you could add something to your script that would have the same
> effect as the -O command-line option.
Something like this would also work:
#!/bin/sh
dummy='''
'
# shell code goes here; Python will ignore it
I wrote:
> #!/bin/sh
> dummy='''
> '
> exec python -O "$0" ${1+"$@"}
> '
> '''
> # Python code goes here
Actually, we don't need the dummy variable:
#!/bin/sh
''':'
exec python -O "$0" ${1+"$@"}
' '''
import sys; print sys.argv
Or for even more fun:
#!/bin/sh
''':'
exec python -O "$0" ${1+"$@"}
Jim Meyering <[EMAIL PROTECTED]> wrote:
> And I'm still reluctant to allow --files-from without --null.
What about --files-from0, or some such, so that the difference between
it and --files-from in other tools is apparent?
paul
___
Bug-coreutils mail
joe smith <[EMAIL PROTECTED]> wrote:
> chmod is suppose to have a switch call "a+x" according to sun,
Sun's documentation describes Sun's chmod program, not GNU's. But
they happen to share this feature anyway.
> but it appear to not have this switch.
Works for me.
$ ls -l foo
-rw-r--r--
Johan Glimming <[EMAIL PROTECTED]> wrote:
> $ cd ~
> $ mkdir a a/b
> $ ln -s a/b b
> $ echo > a/b/y
> $ cd b
> $ mv x .. (or: cp x ..)
>
> The problem here is that x now is in the directory ~/a rather
> than ~ as one would expect, having entered b from ~.
This is not a bug. mv does n
Chris Van Nuys <[EMAIL PROTECTED]> wrote:
>I am submitting a patch for the program 'ls'. This patch changes
> the way that 'ls' output's long_output ('ls -l', -g, etc).
It would be better to add a new option to activate this behavior, so
as not to break existing code that parses ls's output.
Marco Gerards <[EMAIL PROTECTED]> wrote:
> ls -- *file
Alternatively: "ls ./*file". This works even with programs that don't
recognize "--".
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>the echo command doesn't read string sequences such as \c or \r
>even when the option -E is not used.
-e is not supposed to be on by default, AFAICT. I think -E exists
only to override an explicit -e. "/bin/echo -e" works for me.
> echo
Thierry Vignaud <[EMAIL PROTECTED]> wrote:
> $ perl -e 'system("[", "1", "=", "1", "]")'
> $ perl -e 'system("/usr/bin/[", "1", "=", "1", "]")'
> /usr/bin/[: too many arguments
> $ perl -e 'system("/usr/bin/[", "1", "=", "1")'
Just as an aside, you can save some typing:
$ env [ 1 = 1 ]
$ env /usr/
Olivier Delhomme <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~$ /usr/bin/\[ --version | head -n1
> [ (GNU coreutils) 5.0.90
>
> [EMAIL PROTECTED]:~$ [ x = x ] && echo ok
> ok
In the first case, you are using the coreutils "[" command installed
in /usr/bin. In the second case, you are using the
Tjabo Kloppenburg <[EMAIL PROTECTED]> wrote:
> Sometimes I want to pipe something into "cut" and get everything except
> the last character. Or the last 2 characters.
> I could use perl for that, but cut is smaller and should do the job, too.
FWIW, you can do this with sed.
$ echo foo | sed 's/.$/
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
> You could set _POSIX2_VERSION on the GNU/Linux system to 199209. From
> (coreutils)Standards conformance
...
> The GNU utilities normally conform to the version of POSIX that is
> standard for your system. To cause them to conform to a differen
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>I don't understand why should hostname move into inetutils.
>
> Because it is a "internet" tool.
Well, it has sort of become one. But Unix has had hostname longer
than it has had networks, IIRC, and hostname does not do any network
communication
Paul Eggert <[EMAIL PROTECTED]> wrote:
> 2004-01-19 Paul Eggert <[EMAIL PROTECTED]>
>
> * tests/touch/relative: Use TZ=UTC0, not TZ=utc (which isn't
> portable). Problem reported by Christian Krackowizer. Also, use
> + rather than +0 to specify a time zone, as the document
Paul Eggert <[EMAIL PROTECTED]> wrote:
> + * tests/touch/relative: For 'ls' use TZ=UTC0, not TZ=utc (which isn't
> + portable).
OOC, is "TZ=UTC" portable?
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listi
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Perhaps it's because too many people alias "ls" to something else
> using a shell function?
I would have thought aliases would be ignored by a script anyway.
> If so, perhaps the simplest workaround is to replace "command ls"
> with "../../src/ls"
"env ls
Paul Eggert <[EMAIL PROTECTED]> wrote:
> The 'tail -1' behavior change has been around for a couple of years
> anyway: it predates coreutils 4.5.1, the first version of coreutils
> proper. It didn't become much of an issue, though, until systems
> appeared that claimed conformance to the 2001 POSI
"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote:
>Alfred, your quoting makes it hard to tell that the quote from the
>previous message is not just another paragraph taken from the
>manual.
>
> Well, I can start putting normal double-quoting marks around the text
> instead of indenting it w
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> - whether there is a semantic difference between the first hostname and
>> the other ones ("aliases")?
A hostname program does not need to talk to the network at all. The
kernel keeps exactly one hostname i
[EMAIL PROTECTED] (Bob Proulx) wrote:
> But the -f, --fqdn in particular must use DNS if the real hostname
> is not already fully qualified.
Well, that's one way it can try to go about it. There's also
getdomainname(), on systems that have it, or uname(). One might also
argue that it would be re
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Then why is does gethostbyname() return one of the names as h->h_name,
> and the others as h->h_aliases[] ? What's the criterion that makes h->h_name
> the "primary" one?
Well, there need not be a primary name at DNS level, but there can
be. If there isn'
Martin MOKREJ¦ <[EMAIL PROTECTED]> wrote:
> say: by default don't build hostname on Solaris, Irix, where else too?
Defaults should be the same on all platforms, I'd say. Once the full
featured hostname is incorporated into coreutils, I don't see any
reason for it to get special treatment.
>>
Jim Meyering <[EMAIL PROTECTED]> wrote:
> It might even be worthwhile to interpret `\n', \t, \\, etc.
With bash, at least, users can do:
$ stat --format=$'%i\n' file
This seems like the sort of thing that is better left to the shell,
rather than included in each individual program.
paul
__
Jim Meyering <[EMAIL PROTECTED]> wrote:
> The behavior of `ln -s' in that case is compatible with
> historical BSD implementations. You'd like the SYSV behavior.
I think a new option would be useful - I'll call it --syntactic, but
that may not be a good name. --syntactic means that the filenames
Paul Eggert <[EMAIL PROTECTED]> wrote:
> There is some overlap here, as
> "ln --as-is foo bar" would be equivalent to "link foo bar",
Yes, though it would still be useful to combine --as-is with other ln
options like -f.
> "rm --as-is foo" would be equivalent to "unlink foo", and
I didn't sugges
Paul Eggert <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> rm's determination of whether to treat the path as a directory is
>> already determined entirely from the command line, from -r/-R.
>
> Not exactly: if foo is an empty directory,
Jim Meyering <[EMAIL PROTECTED]> wrote:
> There is a discrepancy between POSIX and common practice
> with respect to how `cp -if a b' should work.
Someone probably ought to notify the POSIX folks about that and get a
clarification. Maybe they'll amend the spec to allow the existing
behavior.
pa
Peter Postmus <[EMAIL PROTECTED]> wrote:
> tail -n1 -f /var/log/messages |./festival --tts
...
> However, when the -f option is omitted, the last log entry is spoken
> completely. That's why I suspect this to be a problem in tail, not is
> Festival.
Try this:
tail -n1 -f /var/log/messages | cat
I
[EMAIL PROTECTED] wrote:
> Maybe this could be done with the wc -l behavior for when the last
> line doesn't have a newline? Maybe I'm weird but I think the POSIX
> behavior is clearly counterintuitive.
If existing implementations agree with each other and with POSIX, then
there's no need to chang
Digital <[EMAIL PROTECTED]> wrote:
> As a side comment, There is a BUG with strstr.c
> If haystack gets truncated or there is no trailing '\0', then strstr
> will keep looking past the expected string end into unknown space.
That makes it a dangerous interface, but not a bug. If the caller
fails
Jim Meyering <[EMAIL PROTECTED]> wrote:
>>/* If there is no colon, then see if there's a `.'. */
>> - if (separator == NULL && posix2_version () < 200112)
>> + if (separator == NULL && (posix2_version () < 200112 ||
>> +!getenv ("POSIXLY_CORRECT")))
>
> Please conside
[EMAIL PROTECTED] (Frank Schruefer) wrote:
> cd
> dirname .
> delivers:
> .
> That's totally ok, just no option to get e.g. /home/merlin instead of . .
You can get absolute paths by using "`pwd`" instead of ".".
$ pwd
/home/prj
$ dirname "`pwd`"
/home
Too bad coreutils' pwd doesn't support SUSv3'
Nicholas Stallard <[EMAIL PROTECTED]> wrote:
> Is there any chance that the coreutils hostname could
> accept a -s parameter (with the above mentioned functionality),
> and if omitted, simply behave like it already does?
There was some talk a while back about merging the hostname from
gettext into
Jeff Silverman <[EMAIL PROTECTED]> wrote:
> But for files such as /etc/fstab, where the fields are delimited by
> any amount of white space, cut doesn't work so well.
Have you tried awk?
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://ma
1 - 100 of 131 matches
Mail list logo
