If you execute cp /path/* the command expands the wildcard, and
treats the last file as the destination directory.
That is at it should be, * is expanded by the shell, not by the command.
$ diff --git
diff: unrecognized option '--git'
I think diff should say at this point real diff, at least up to year
2010, does not have a --git option, you are probably getting that idea
from git output or something.
That is what it says, though not in so many words. Having an
/bin/echo -e \\x2Dn
Alas, -e is not guaranteed by POSIX.
A friend came up with this hack `echo -n\ '; note the space. Which is
a bit of a cheat. And `echo -e --\\bn', which alas is not POSIXly.
Here is a fun one, how does one output `-n' (literal string) (or any
other option that echo accepts) using echo?
$ /bin/echo --version|head -n1
echo (GNU coreutils) 8.4
$ /bin/echo -- -n
-- -n
$ /bin/echo - -n
- -n
$ /bin/echo '-n'
$ /bin/echo -n
$
Ah, Bob, you're really no fun! Neither printf, piping to sed or cat
are fun solutions. :-) And no, I don't have an ace up my sleeve...
What are all the exit statuses I need to check just after expr
command? Is it only need to check 1 or 2 or 3 for fail condition
and zero for success ?else pease specify
You only need to check for non-zero exit codes for failure.
The following might work: make -C src foo.o
I'm wondering if there is a similar program to 'head' that accepts gz
files. (just as zgrep to grep)
You can use: zcat foo.gz | head
Any program listed in --enable-no-install-program won't get its man
pages generated during dist/distcheck, so currently to install those
man pages on needs have perl installed to be able to run help2man.
Not sure what the best way is to fix this, thoughts?
Why the name of command was changed from finger to pinky? I
liked new name, but there may be Some old scripts (copied from
Unix to Linux) in which finger may have used. I suggested finger
as a link to pinky.
As far as I know pinky is not a replacement for finger but is instead
The list of uids are already public in the /etc/passwd file. That file
is already world readable. Therefore it isn't clear to me how using
another command makes this a vulnerability.
Using fingerd, this could disclose login names to remote attackers.
This, of course, does not
tail +n is a obsolete syntax, and was deprecate in POSIX 1003.1-2001.
From the coreutils manual:
| Standards conformance
| ==
|
| In a few cases, the GNU utilities' default behavior is incompatible
| with the POSIX standard. To suppress these incompatibilities, define
|
This command that accepts the -f option is *not* the GNU hostname
command.
There is a small confusion, there are two versions of GNU hostname.
One that supports -f (GNU Inetutils hostname), and one that doesn't
(GNU Coreutils hostname). The one in coreutils is not installed by
default.
What's the justification for putting incomplete information in the
manpages that's already available to another text tool on the same
package?
It is a compromise for users like yourself who expect things to be in
man pages (the man pages we produce as really --help formated using
troff;
The standard for documentation has been man for longer than that...
It should be complete.
Maybe for some old UNIX systems, but this has never been the case for
GNU.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
The standard for documentation has been man for longer than
that... It should be complete.
Maybe for some old UNIX systems, but this has never been the case
for GNU.
And many current ones. As for GNU, it isn't a complete system
anyways...
GNU became complete
migration of coreutils works into the public domain
I know of no such plan.
I'm refering to the copyright term limits which apply to all works,
not a specific plan for coreutils.
It doesn't affect it at all, if you use a version of coreutils from
1980, then the copyright term
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
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
go
can you please also read, and follow
http://lists.gnu.org/archive/html/autoconf/2009-05/msg00058.html?
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
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
+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
+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
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.
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
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
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?
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 mirror
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
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.
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
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
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
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
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; fi;
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
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.
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
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!
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
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
Dr. David Alan Gilbert wrote on 27-01-08 01:29:
Hi,
Out of a bit of boredom (and avoiding trying to fix a VHDL problem)
I decided to graph the sizes of a few of the binaries from coreutils,
as packaged by debian over time (I've included fileutils/shellutils).
What is the drop at 9 epoch? That one looks fun; I am
guessing it is the move to glibc 2.x?
Yes, it appears to be - the first one is linked against libc.so.5
and an earlier dynamic linker I don't have.
This might put a different spin in the size increase, that it is glibc
i still want to know whether the problem i say is a bug or not!!
It isn't a bug. You are telling ln to create a symbolic link that
points to itself.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
FWIW, GNU tar uses argp for parsing arguments.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
1. It does a significant part of the work at compile time. So the
generated code can be quite simple and fast.
It is parsing arguments, it doesn't need to be super fast. As for
simplicity, having used argp for alot of things, I all I know is that
getopt/getopt_long are a pain.
2. It
Debarshi Ray [EMAIL PROTECTED] converted a bunch of tools in
inetutils (http://www.gnu.org/s/inetutils/,
http://sv.gnu.org/p/inetutils/) to use argp instead of
getopt/getopt_long. Some which have quite hairy parsing
semantics, for example ping which uses children parsers, but
Hello, I want to ask the developers what do they think about
implementing a way to do cp -r .* target (copy files and
directories starting with dot) without copying the parent directory
.. (I think that's what the user usually intends to do)
Won't work, globs is expanded by the shell
when executed with file name containing spaces, basename returns only
first part of file name (until space).
Try quoting the string.
[EMAIL PROTECTED]:~$ basename /home/ams/frob ni.cate
frob ni.cate
Space is treated as a seperator of arguments on GNU and Unixoid
systems.
Oh, and I'm overlooking these:
groupsis in the shadow package too
idis in the shadow package too
On GNU systems, like GNU/Linux, it is only appropriate to install the
GNU version of these programs by default. The problem with su is that
it requires root access to be
--- /dev/null
+++ b/man/arch.x
@@ -0,0 +1,6 @@
+[NAME]
+uname \- print machine hardware name (same as uname -m)
That should be `arch \- print machine ...'.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Current stable version of coreutils (6.9) has 8(!) utilities
which somehow compute or/and check a message digest. They are:
'md5sum', 'sha1sum', 'sha224sum', 'sha256sum', 'sha384sum',
'sha512sum' and finally 'sum' and 'cksum'. It's already a little
bit confusing and it seems
I don't see any major problem why something like `hashsum
ALGORITHM' wouldn't work though, `md5sum' could be the same as
`hashsum md5'. And then md5sum could be a shell script, or just
a simple program that calls `hashsum md5'.
Except that since the *sum utilities operate on
Why not just: hashsum ALGORITHM [FILE]? A optional hashing
algorithm seems pointless for this.
Because on decoding, 'hashsum -c FILE' could be made smart enough
to auto-detect the algorithm based on the length of the hash, but
only if the algorithm is optional (--md5) rather than
On the linux man page for cp one is directed to info cp but
this will not work because info cp describes the C/C++
preprocessor.
This is a known issue with info, aggravated by the fact that
man2info insists on listing the shorter link when generating the
man page whether or
SI does not define what a kilo-byte is, computer scientists do, and they
defined it as 1024.
Being a CS, I like consistency, and I also happen to like kilo-byte ==
1000 bytes. :-)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
when you do ls -l -h one sometimes encounters files which have kilo
size. ls -l -h then uses K to display this. This is wrong and
unallowable. It must be k. You don't have a choice: it is
standarised by the SI system as k. See for example
http://en.wikipedia.org/wiki/SI .
That's probably because you can do all these things with find(1).
In any case it's very unlikely that any more single-letter options
will be added to the coreutils ls because of the likelihood of
some conflict with other ls implementations.
Not to mention that all single-letter
Regarding the original query, why not just use awk?
Or just use basename with a little xargs added. This seems very
readable and obvious to me.
echo /home/me/foo | xargs -l basename
foo
And then zero terminated strings are already supported.
printf /home/me/foo\0
Hmm - making basename (and also dirname) a filter is compatible
with POSIX: since POSIX requires a single argument, we can define
operation with a missing argument however we want (or in other
words, our current definition of issuing an error is not mandated).
If we do that, then we
All great ideas, but who is willing to code them?
I think the OP seemed quite motivated for the task.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Furthermore, with a --suffix option, we could also allow multiple
command line arguments, another usage case that might prove
useful:
$ basename --suffix=.h foo.h bar.h
It's always fun until somebody puts out an eye by having a file named
--suffix=.h.
Handle it the
I'm somewhat positive about the idea, but this particular name has
the problem that it's already used for other projects (or at least
that is what searching for the name on the web would imply).
What project is that? I'm quite fond of the name, maybe etcutils
would be
For example:
http://www.google.com/search?hl=enq=miscutilsbtnI=I'm+Feeling+Luckymeta=
Could you explain what that contains? I don't have access to a
webbrowser.
The first hit in google is Miscutils-1.0.0 in CPAN. There are
92,700 hits in google for miscutils
I
What about coreutils-extra? (Would that be acceptable to the
coreutils folks?)
These are not extra utilities for coreutils, so this name is not suitable.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
I should note that I'm still waiting for the someone to step up as
miscutils maintainer, [EMAIL PROTECTED] never got back to me about it.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
if --remove (-u) is specified. The default is not to remove the
files because it is common to operate on device files like
/dev/hda, and those files usually should not be removed. When
operating on regular files, most people use the --remove option.
Why not use the stat system
[EMAIL PROTECTED] NZ PostSep06]$ echo `pwd`
/home/corrin/NZ PostSep06
[EMAIL PROTECTED] NZ PostSep06]$ basename `pwd`
NZ
[EMAIL PROTECTED] NZ PostSep06]$ basename --version
basename (GNU coreutils) 5.2.1
Written by FIXME unknown.
Surely the correct output is NZ PostSep06?
Btw, the #ifdef __GLIBC__ in m4/fsusage.m4 looks wrong also for
the Hurd, because glibc/sysdeps/mach/hurd/statfs64.c does not
appear to access /proc.
/proc doesn't exist on GNU, never did.
Cheers.
___
Bug-coreutils mailing list
This is a bug in your GNU/Linux system, you should report it to the
people who maintain it.
The behaviour you see probobly happens because your shell initialision
file doesn't do:
eval `dircolors /etc/DIR_COLORS`
or similar.
Happy hacking.
___
While I'm not that proficient in these issues,
Nor am i.
But I am.
/* Return the io server port for file descriptor FD. This adds a
Mach user reference to the returned port. On error, sets
`errno' and returns MACH_PORT_NULL. */
Thanks, that looks quite promising.
Breaking backward compatibility is so bad -- I've been bitten many
times by autoconf-generated scripts that many GNU packages use and
insist on remaking locally (why?) and that could not work because
my local autoconf was newer than the version used by the package
author.
There's a bug in recent tail: it claims tail +20 is deprecated
and I should use tail -n +20.
It isn't a bug, it is intended. (coreutils)Standards conformance:
|Newer versions of POSIX are occasionally incompatible with older
| versions. For example, older versions of POSIX required
(2) I don't think many people are relying on this behavior. (Why
would you want to run tail -f on a pipe?)
Agreed. That does seem freaky. I can't think of a useful case for
it.
I can't think of a specific or concrete case right now, but `tail -f'
on a pipe could be used on
GNU/Linux_box:/ # expr 10 / 2
5
GNU/Linux_box:/ # expr 10 * 2
expr: syntax error
You need to escape the multiplication sign. Try:
expr 10 \* 2
And try:
echo expr 10 * 2
to see why it doesn't work (shell expansion)
Cheers.
___
I am trying to open a file called -2.xml through VI editor/cat
from command prompt. But unable to read the file as it is taking
- as one option. I am getting the following error - cat: invalid
option -- 2
Try: COMMAND ./-2.xml
where COMMAND is vi/cat/...
Cheers.
I compiled without problem coreutils 5.93, but when I executed
make check there was one failed test. The failed test was
close-stdout
You haven't given any information about the system you compiled GNU
coreutils 5.93 on, so it is hard to figure out what might have gone
wrong.
The
Ideally, info would be fixed to allow an exact-match, rather than
the current, first-match approach.
Or better yet, extending --show-options so you can pass a program to
it. Say, info --show-options pr coreutils.
___
Bug-coreutils mailing list
I was wondering if that [ program is supposed to be there, or if
it's a typo. If I run info [ I get the info page for test, so I
wasn't certain if they were related.
They are the same, [ is for systems that don't have [ builtin into the
shell. Consider the following shell expresion:
Except that '[' is a built-in with most shells today. But for
older shells it was an external command.
I think it is important to note that GNU [ supports more fancy things
than the default GNU bash builtin; or atleast, used too...
___
[The bug-sh-utils list is obsolete, use bug-coreutils instead]
Would it be possible to make everything that goes to
bug-{text,sh,files}-utils end up in bug-coreutils? Or maybe it
already does...
When using /usr/bin/env as the interpreter in a #! line, you must
be sure that there is
Also, /usr/bin/env is a very non-standard place for env; it is usually
located in /bin.
On what systems is env located in /bin/env? The normal location is
in /usr/bin/env.
GNU for one. :-)
___
Bug-coreutils mailing list
sort -b not only ignores blanks, but also tabs.
A tab is a blank.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Perhaps it would be more clear to say whitespace instead. Or are
there types of whitespace other than 'spaces, tabs and newlines',
which do not get ignored?
I think the locale comes into play here too, so saying anything
specific would be wrong. And what is the difference between
The former could be interpreted as a single blank, which could
then map very easily onto a single space (since no other form of
whitespace produces a single column's worth of change), but there
is no such thing as a single whitespace in intuitive
interpretation; whitespace is a
So how can I find the supplementary groups of process 4321 using id
or groups? It does't seem to be possible.
You'd need to hack a bit for that to work. Something like I dunno:
[EMAIL PROTECTED]:~$ id `ps -up 2551|tail -n1|awk '{print $1}'`
uid=30270(ams) gid=134(update)
EVIL. You are calling qsort twice for every element (once to
put directories first, then twice again on the subsets). This
is twice as slow as just writing a proper sort function that
does everything all in one comparison, so that you only call
qsort once.
I agree with
ok, I'll keep it in mind when I'll redo the patch. I'll keep only
the --group-dirs option and remove -e.
--sort-directories-first is I think a clearer name, --group-dirs says
nothing about how the directories are group, if there are several
groups, etc. If --sort-directories-first is to
So, you coreutils developers should just converge me on a suitable
name and I'll use it in my patch (which in any case I don't pretend
to be applied verbatim ;)).
Can you send the patch to the list? I can take a quick peek at it and
see if there are things that are missing that I'm
Eek, sorry for putting my nose into this. But you just touched me in
a sensetive spot! So I appologise in advance! :)
--- coreutils-5.92/tests/du/2g.orig 2005-11-09 03:12:19.18192 -0500
+++ coreutils-5.92/tests/du/2g 2005-11-09 03:59:42.27477 -0500
@@ -14,7 +14,23 @@
Maybe GNU/Hurd is fancy enough; I don't know.
I don't know if it is possible _right_now_, but it shouldn't be hard
to implement such a feature.
That being said, it'd definitely be a nice feature to have, and if
someone implements it cleanly I'd like to see it included in GNU
nohup.
This should bomb out right away,
$ install -d /var/lib/dpkg/status /tmp/var/lib/dpkg/status
install: `/var/lib/dpkg/status' exists but is not a directory
instead of still creating /tmp/var/lib/dpkg/status.
Why?
No idea, but one could add a option that makes install exit on
sleep (GNU sh-utils) 2.0
You should upgrade, the current version is 5.2.1, you can grab a
tarball of coreutils (union of {sh,text,file}-utils) from your local
GNU mirror.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
`tail -f /dev/zero` eats all the available memory and swap until
tail gets killed by the OOM killer (on linux, at least).
Since /dev/zero is of infinite size, tail does the right thing in
reading it until all memory/swap is exhausted.
,[ (standards)Semantics ]
| 4.1 Writing Robust
The GNU su is host specific enough that there has been discussion
of removing it from coreutils and moving it into a hostutils
package.
FYI, there is a GNU project called sysutils exactly for this type of
stuff.
And the mind boogles why GNU su must run on non-GNU platforms, why not
At which point would the arbitrary limit become acceptable?
Never.
10MB of data seems big enough to avoid hitting the case on any
normal file, for example.
8 char. long user seemed big enough, 2 char. years seemd big enough,
argument lists of 1024 chars seemd long enough, etc etc.
The command in question might be run anywhere (the documentation
talks about scripts). That would include /tmp.
`rm *' might also be run from anywhere, hence why don't get it.
Sorry for being dense...
___
Bug-coreutils mailing list
I think the point that was trying to be made is the following - if
the user does
$ cd /tmp
$ rm *
then they know exactly why files are being removed. But if they do
Not if * gets expanded to `-rf /home/ams'.
$ cd /tmp
$ eval `dircolors`
then they don't expect any side
I had expected that omitting this command would make coloration
disappear, but this is not the case. Why is that?
...
alias ls='ls --color=auto'
Thats why, ls has defaults for colors.
___
Bug-coreutils mailing
1 - 100 of 211 matches
Mail list logo
