Re: Pinky command

[Erik Auerswald]

Hi,

On Wed, Nov 11, 2009 at 06:15:32PM -0700, Bob Proulx wrote:
> hemant.ru...@us.ing.com wrote:
> > In old days, attackers used to create .project symbolic to passwd
> > and group files to get the List of login ids and group via
> > fingerd.
> 
> 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 apply to local invokation of some tool that
uses normal user privileges.

Erik
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Pinky command

[Bob Proulx]

hemant.ru...@us.ing.com wrote:
> In old days, attackers used to create .project symbolic to passwd
> and group files to get the List of login ids and group via
> fingerd.

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.

> I guess, Sun had fixed this long back in Solaris. However
> in pinky, I can use symbolic link to /etc/passwd and /etc/group.

Do you have any references on the fix for this attack vector?

> $ cd  <--- Go to home dir 
> $ ln -s .project  /etc/passwd 

Obviously that should be switched. :-)

> $ pinky -l  mylogin 
> 
> Pinky follows symlink of .project. I guess, Pinky should avoid .project
> if it is a symlink. 

Compare this "attack":

  $ ln -s /etc/passwd .project
  $ cat .project

To this one:

  $ cat /etc/passwd

How is finger/pinky more vulnerable than cat?

Bob

Pinky command

[Hemant . Rumde]

Hi GNU Bug fixers, 

I am old school and has been using finger ( without fingerd for security
reasons ) on Unix. 
Today I came across pinky on RedHat Linux. The man page of this command 
specified your email address. 

In old days, attackers used to create .project symbolic to passwd and
group files to get the 
List of login ids and group via fingerd. I guess, Sun had fixed this
long back in 
Solaris. However in pinky, I can use symbolic link to /etc/passwd and
/etc/group. 

$ cd  <--- Go to home dir 
$ ln -s .project  /etc/passwd 
$ pinky -l  mylogin 

Pinky follows symlink of .project. I guess, Pinky should avoid .project
if it is a symlink. 

Hemant 
ING U.S. Financial Services 
Shared Application Engineering - Enabling Technologies 
Phone: 617-376-4298  
hemant.ru...@us.ing.com 
www.ing-usa.com 
ING. Your future. Made easier.SM 



-

NOTICE: The information contained in this electronic mail message is 
confidential and intended only for certain recipients.  If you are not an 
intended recipient, you are hereby notified that any disclosure, reproduction, 
distribution or other use of this communication and any attachments is strictly 
prohibited.  If you have received this communication in error, please notify 
the sender by reply transmission and delete the message without copying or 
disclosing it.

Re: rfc: exposing *at functions to shell

[Andreas Schwab]

Mike Frysinger  writes:

> On Wednesday 11 November 2009 18:13:41 Andreas Schwab wrote:
>> Eric Blake  writes:
>> > Mike Frysinger writes:
>> >> --at-fd might be a better explicit option without getting too verbose ?
>> >
>> > Indeed.
>> 
>> Note that the "at" in those functions is actually short for "attribute".
>
> i wasnt aware of that, and the posix docs dont seem to use this word in any 
> of 
> the function descriptions.

Sun originally invented them to access the extended attributes of a file
which are organized in a kind of hidden filesystem rooted at the file's
inode.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: rfc: exposing *at functions to shell

[Mike Frysinger]

On Wednesday 11 November 2009 18:13:41 Andreas Schwab wrote:
> Eric Blake  writes:
> > Mike Frysinger writes:
> >> --at-fd might be a better explicit option without getting too verbose ?
> >
> > Indeed.
> 
> Note that the "at" in those functions is actually short for "attribute".

i wasnt aware of that, and the posix docs dont seem to use this word in any of 
the function descriptions.  i dont think it matters much though with the 
longer proposed option as it still means "the fd given to the *at funcs".  if 
anything, it makes it clearer as you wouldnt interpret it to mean "use these 
other AT options when calling *at funcs".
-mike


signature.asc
Description: This is a digitally signed message part.

Re: rfc: exposing *at functions to shell

[Andreas Schwab]

Eric Blake  writes:

> Mike Frysinger  gentoo.org> writes:
>
>> --at-fd might be a better explicit option without getting too verbose ?
>
> Indeed.

Note that the "at" in those functions is actually short for "attribute".

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: rfc: exposing *at functions to shell

[Eric Blake]

Mike Frysinger  gentoo.org> writes:

> > cd /tmp
> > mkdir -p sub
> > {
> >   ln --at=4 -sf foo bar   # call symlinkat("foo",4,"bar")
> >   readlink --at=4 -m bar  # call areadlinkat(4,"bar")
> > } 4< sub
> > 
> > would output /tmp/sub/foo.
> 
> isnt this possible today under linux by using /proc/self/fd ?  i'm not 
> suggesting this as a clean/portable replacement, just trying to better 
> understand the proposal.

Yes, with sufficient /proc supprt, the above example would be equivalent to:

cd /tmp
mkdir -p sub
{
  ln -sf foo /proc/self/4/bar
  readlink -m /proc/self/4/bar
} 4< sub

Without /proc, it's similar to doing everything via absolute or anchored paths 
(or using shell variables for shorthand), but then you lose time with O(n^2) on 
deep nesting of directories, as well as the robustness that the *at functions 
give in the case that some other process is modifying the same hierarchy that 
you are operating on:

cd /tmp
mkdir -p sub
dir=sub
{
  ln -sf foo "$dir"/bar
  readlink -m "$dir"/bar
} 4< "$dir"

> --at-fd might be a better explicit option without getting too verbose ?

Indeed.

-- 
Eric Blake

Re: rfc: exposing *at functions to shell

[Mike Frysinger]

On Wednesday 11 November 2009 17:13:04 Eric Blake wrote:
> Here's a thought (no immediate rush to implement, though).  Should we
>  expose various *at functions to shell scripting, by adding a new option to
>  specify which fd to pass as the directory argument?  This would allow the
>  creation of virtual directory change semantics without the cost of forking
>  a subshell around a cd command.  For an envisioned example,
> 
> cd /tmp
> mkdir -p sub
> {
>   ln --at=4 -sf foo bar   # call symlinkat("foo",4,"bar")
>   readlink --at=4 -m bar  # call areadlinkat(4,"bar")
> } 4< sub
> 
> would output /tmp/sub/foo.

isnt this possible today under linux by using /proc/self/fd ?  i'm not 
suggesting this as a clean/portable replacement, just trying to better 
understand the proposal.

--at-fd might be a better explicit option without getting too verbose ?
-mike


signature.asc
Description: This is a digitally signed message part.

rfc: exposing *at functions to shell

[Eric Blake]

Here's a thought (no immediate rush to implement, though).  Should we expose 
various *at functions to shell scripting, by adding a new option to specify 
which fd to pass as the directory argument?  This would allow the creation of 
virtual directory change semantics without the cost of forking a subshell 
around a cd command.  For an envisioned example,

cd /tmp
mkdir -p sub
{
  ln --at=4 -sf foo bar   # call symlinkat("foo",4,"bar")
  readlink --at=4 -m bar  # call areadlinkat(4,"bar")
} 4< sub

would output /tmp/sub/foo.

It may also make sense to add some shell support in bash for a new redirection 
operator that opens a directory with O_SEARCH, rather than using < for 
O_RDONLY, to benefit from the additional POSIX semantics of O_SEARCH on 
platforms that support that distinction; maybe '><', as in 'exec 4>< dir'.  
Also, using --at only helps for command line arguments; a new redirection 
operator that can specify a directory fd for interpreting relative names would 
also be useful in the shell to make this proposal fully worthwhile; although 
here I have no ideas for a decent syntax extension beyond POSIX.

Also, maybe it should be spelled something longer, like --relative-to-fd, 
rather than --at?

First round of apps to consider this for: anything that modifies file metadata 
or does low-level operations
chcon
chgrp
chmod
chown
cp
dd
du
install
link
ln
mkdir
mkfifo
mknod
mv
pathchk
readlink
rm
rmdir
stat
touch
truncate
unlink

Second round of apps: anything that calls open on command line arguments, such 
as head, tail, cat

-- 
Eric Blake

Re: incorrectly sorted file with snow leopard sort

[Andreas Schwab]

Bauke Jan Douma  writes:

> Eric Blake wrote on 11/04/2009 02:59 AM:
>
>>> $ cat list-of-groups-greetings.txt | tr -d "\r" | sort
>>
>> Useless use of cat.
>>
>> tr -d "\r" < list-of-groups-greetings.txt | sort
>
> Useless maybe, but then again maybe the user won some time
> by it. I often wind up with constructs like this.
>
> Many times, you do 'less /path/to/file', then right after you
> may want to run sed or grep on it, in which case I usually
> find it quicker to edit the previous command-line as little
> as I can, and just attach the grep or sed or whatever-command
> to it: 'less /path/to/file | grep regex'.

$ < list-of-groups-greetings.txt tr -d "\r" | sort

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: incorrectly sorted file with snow leopard sort

[Bob Proulx]

Bauke Jan Douma wrote:
> Eric Blake wrote on 11/04/2009 02:59 AM:
>> Useless use of cat.
>> tr -d "\r" < list-of-groups-greetings.txt | sort
>
> Useless maybe, but then again maybe the user won some time
> by it. I often wind up with constructs like this.
>
> Many times, you do 'less /path/to/file', then right after you
> may want to run sed or grep on it, in which case I usually
> find it quicker to edit the previous command-line as little
> as I can, and just attach the grep or sed or whatever-command
> to it: 'less /path/to/file | grep regex'.
>
> An many times --this may be hurtful ;-)-- I wind up doing 'cat
> file' on too large a file, followed by a quick command-
> line edit that gives me: 'cat file | less'.
>
> Basically, I think I (my fingers?, my eyes?) have trouble
> getting to the '<'. I'm not a touch typist by any means.

I don't think anyone worries about anything written on the command
line.  If you are typing it and hitting enter then do whatever makes
sense to you.

The problem is that those command lines tend to make their way into
scripts.  It is in scripts that some of these constructs cause more
problems.  Doing character I/O can actually be quite CPU intensive.  I
have often benchmarked and found large optimizations there.  It does
keep those multicore processors busy! :-)

Bob

Re: incorrectly sorted file with snow leopard sort

[Bauke Jan Douma]

Eric Blake wrote on 11/04/2009 02:59 AM:

>> $ cat list-of-groups-greetings.txt | tr -d "\r" | sort
>
> Useless use of cat.
>
> tr -d "\r" < list-of-groups-greetings.txt | sort

Useless maybe, but then again maybe the user won some time
by it. I often wind up with constructs like this.

Many times, you do 'less /path/to/file', then right after you
may want to run sed or grep on it, in which case I usually
find it quicker to edit the previous command-line as little
as I can, and just attach the grep or sed or whatever-command
to it: 'less /path/to/file | grep regex'.

And many times --this may be hurtful ;-) -- I wind up doing 'cat
file' on too large a file, followed by a quick command-
line edit that gives me: 'cat file | less'.

Basically, I think I (my fingers?, my eyes?) have trouble
getting to the '<'. I'm not a touch typist by any means.

bjd

Re: incorrectly sorted file with snow leopard sort

[Bauke Jan Douma]

Eric Blake wrote on 11/04/2009 02:59 AM:


$ cat list-of-groups-greetings.txt | tr -d "\r" | sort


Useless use of cat.

tr -d "\r" < list-of-groups-greetings.txt | sort


Useless maybe, but then again maybe the user won some time
by it. I often wind up with constructs like this.

Many times, you do 'less /path/to/file', then right after you
may want to run sed or grep on it, in which case I usually
find it quicker to edit the previous command-line as little
as I can, and just attach the grep or sed or whatever-command
to it: 'less /path/to/file | grep regex'.

An many times --this may be hurtful ;-)-- I wind up doing 'cat
file' on too large a file, followed by a quick command-
line edit that gives me: 'cat file | less'.

Basically, I think I (my fingers?, my eyes?) have trouble
getting to the '<'. I'm not a touch typist by any means.

bjd

Re: FW: Documentation of POSIXLY_CORRECT

[Eric Blake]

Pádraig Brady  draigBrady.com> writes:

> > $ export POSIXLY_CORRECT
> 
> That should be: export POSIXLY_CORRECT=

Indeed; and that was the key piece I overlooked.  'export POSIXLY_CORRECT' 
merely marks POSIXLY_CORRECT for exportation, _iff_ it has a defined value; 
export POSIXLY_CORRECT both marks POSIXLY_CORRECT for exportation and assigns 
it a value.

By the way, if you want to be portable to Solaris /bin/sh, you have to use:

export POSIXLY_CORRECT
POSIXLY_CORRECT=

(the two lines can appear in either order).

-- 
Eric Blake

Re: FW: Documentation of POSIXLY_CORRECT

[Pádraig Brady]

Schwarz, Konrad wrote:
>  
> 
> -Original Message-
> From: Schwarz, Konrad 
> Sent: Wednesday, November 11, 2009 2:31 PM
> To: 'Eric Blake'
> Subject: RE: Documentation of POSIXLY_CORRECT
> 
> Hello Eric,
> 
> thanks for taking this up.
> 
> Here is a session transcript that exhibits the bug:
> 
> $ unset POSIXLY_CORRECT
> $ du test_sequence_1_1_ENF
> 56  test_sequence_1_1_ENF
> $ export POSIXLY_CORRECT

That should be: export POSIXLY_CORRECT=

> $ du test_sequence_1_1_ENF
> 56  test_sequence_1_1_ENF
> $ POSIXLY_CORRECT=1
> $ du test_sequence_1_1_ENF
> 112 test_sequence_1_1_ENF
> $ 
> 

You can also check with:
POSIXLY_CORRECT= du test_sequence_1_1_ENF

cheers,
Pádraig.

Re: Documentation of POSIXLY_CORRECT

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[please keep the list in the loop, and please don't top-post on technical
discussions]

According to Schwarz, Konrad on 11/11/2009 6:31 AM:
> Hello Eric,
> 
> thanks for taking this up.
> 
> Here is a session transcript that exhibits the bug:
> 
> $ unset POSIXLY_CORRECT
> $ du test_sequence_1_1_ENF
> 56  test_sequence_1_1_ENF
> $ export POSIXLY_CORRECT
> $ du test_sequence_1_1_ENF
> 56  test_sequence_1_1_ENF
> $ POSIXLY_CORRECT=1
> $ du test_sequence_1_1_ENF
> 112 test_sequence_1_1_ENF
> $ 
> 
> Note that the number of blocks changes only after POSIXLY_CORRECT has been 
> set to one.  POSIX mandates 512-byte blocks, Coreutils uses 1024-byte blocks 
> by default.

Yes, your session demonstrates what looks like a bug, but I still don't
see how it is possible from the source.  Are you sure you don't have other
variables set, such as DU_BLOCK_SIZE, BLOCK_SIZE, or BLOCKSIZE, which
might also be interfering?

The source code for block size, lib/human.c, uses:

  return getenv ("POSIXLY_CORRECT") ? 512 : DEFAULT_BLOCK_SIZE;

which again does not care whether the POSIXLY_CORRECT variable is empty,
so I can't see where your behavior is coming from.

> 
> Some version information:
> 
> $ du --version
> du (GNU coreutils) 6.12

Have you tried this with coreutils 8.0?

> $ uname -a
> Linux mchn144c 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200 x86_64 
> x86
> _64 x86_64 GNU/Linux
> $
> 
> What else would you like to know?
> 

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr6v3kACgkQ84KuGfSFAYDhRgCfbNHANmiHh/BOjgkR7TPiyGcU
UhAAn1dbkSfuY7p+sNknQVoZE/lP1PEq
=xWYG
-END PGP SIGNATURE-

FW: Documentation of POSIXLY_CORRECT

[Schwarz, Konrad]

 

-Original Message-
From: Schwarz, Konrad 
Sent: Wednesday, November 11, 2009 2:31 PM
To: 'Eric Blake'
Subject: RE: Documentation of POSIXLY_CORRECT

Hello Eric,

thanks for taking this up.

Here is a session transcript that exhibits the bug:

$ unset POSIXLY_CORRECT
$ du test_sequence_1_1_ENF
56  test_sequence_1_1_ENF
$ export POSIXLY_CORRECT
$ du test_sequence_1_1_ENF
56  test_sequence_1_1_ENF
$ POSIXLY_CORRECT=1
$ du test_sequence_1_1_ENF
112 test_sequence_1_1_ENF
$ 

Note that the number of blocks changes only after POSIXLY_CORRECT has been set 
to one.  POSIX mandates 512-byte blocks, Coreutils uses 1024-byte blocks by 
default.

Some version information:

$ du --version
du (GNU coreutils) 6.12
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjörn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.
$ uname -a
Linux mchn144c 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200 x86_64 x86
_64 x86_64 GNU/Linux
$

What else would you like to know?

Konrad

> -Original Message-
> From: Eric Blake [mailto:e...@byu.net] 
> Sent: Wednesday, November 11, 2009 2:05 PM
> To: Schwarz, Konrad
> Cc: bug-coreutils@gnu.org
> Subject: Re: Documentation of POSIXLY_CORRECT
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Schwarz, Konrad on 11/11/2009 4:45 AM:
> > The current text says "[...] define the `POSIXLY_CORRECT' 
> environment variable."  I took this to mean that the variable 
> needs to be exported (export POSIXLY_CORRECT),
> 
> Correct.
> 
> > but it needs to be set to a value as well, at least for du(1).
> 
> That would be a bug, if it were true.  But I can't see anything in the
> source for du that inspects the value of POSIXLY_CORRECT.  
> lib/getopt.c
> uses !!getenv ("POSIXLY_CORRECT") to decide whether to do POSIX option
> parsing, and src/du.c has no reference to POSIXLY_CORRECT.  In fact, I
> couldn't find anywhere in coreutils sources that dereferences 
> the value
> returned by getenv("POSIXLY_CORRECT").
> 
> What version of du are you using?
> 
> - --
> Don't work too hard, make some time for fun as well!
> 
> Eric Blake e...@byu.net
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkr6toEACgkQ84KuGfSFAYCX4QCgzXZPMX8aQlAs8RksD0Me44pA
> iZsAoM4Wijidy6CLgMGMTrtsrUicm5MF
> =YwDS
> -END PGP SIGNATURE-
> 

Re: FW: +N option in tail command

[Philip Rowlands]

On Wed, 11 Nov 2009, נחשון ישורון/Nachshon Yeshurun wrote:


Man pages for the tail command shows the ability to use the +N option.
Yet, attempting it on Ubuntu 9.10 results in an error.
Is this a bug?


Not a bug.


From man pages:

 -n, --lines=N
 output the last N lines, instead of the last 10; or  use  +N  to
 output lines starting with the Nth


Attempting the command:

nachs...@nachshon-ubuntu-vm:~/temp$ tail +5 /etc/passwd
tail: cannot open `+5' for reading: No such file or directory


The manpage syntax should be read as
$ tail -n +5
or
$ tail --lines=+5


Regarding the bare "tail +5" and the issues surrounding this usage 
please see:

http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails


Cheers,
Phil

Re: Documentation of POSIXLY_CORRECT

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Schwarz, Konrad on 11/11/2009 4:45 AM:
> The current text says "[...] define the `POSIXLY_CORRECT' environment 
> variable."  I took this to mean that the variable needs to be exported 
> (export POSIXLY_CORRECT),

Correct.

> but it needs to be set to a value as well, at least for du(1).

That would be a bug, if it were true.  But I can't see anything in the
source for du that inspects the value of POSIXLY_CORRECT.  lib/getopt.c
uses !!getenv ("POSIXLY_CORRECT") to decide whether to do POSIX option
parsing, and src/du.c has no reference to POSIXLY_CORRECT.  In fact, I
couldn't find anywhere in coreutils sources that dereferences the value
returned by getenv("POSIXLY_CORRECT").

What version of du are you using?

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr6toEACgkQ84KuGfSFAYCX4QCgzXZPMX8aQlAs8RksD0Me44pA
iZsAoM4Wijidy6CLgMGMTrtsrUicm5MF
=YwDS
-END PGP SIGNATURE-

Re: FW: +N option in tail command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to נחשון ישורון/Nachshon Yeshurun on 11/11/2009 12:11 AM:
> Hello
> 
> Man pages for the tail command shows the ability to use the +N option.

No, the man pages mention the ability to use the option -n+N.

In fact, because that was so confusing, it has recently been changed.  If
you were to upgrade to coreutils 8.0, you'd see this instead:

  -n, --lines=Koutput the last K lines, instead of the last 10;
   or use -n +K to output lines starting with the Kth

to try to reduce the confusion between the option (-n) and the argument to
the option (+K).

> Is this a bug?

No.  And it is a FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr6tacACgkQ84KuGfSFAYBmVQCfcnhDNfwVaDc3YO7Y2ky0WVUf
ZIQAnREALS8rnmCkDNJM7JSvjc4vhOz+
=gcyd
-END PGP SIGNATURE-

Documentation of POSIXLY_CORRECT

[Schwarz, Konrad]

Hi,

Section 2.11, Standards conformance, of coreutils.info is worded ambigously 
with regards to POSIXLY_CORRECT.

The current text says "[...] define the `POSIXLY_CORRECT' environment 
variable."  I took this to mean that the variable needs to be exported (export 
POSIXLY_CORRECT), but it needs to be set to a value as well, at least for du(1).

This ambiguity can be avoided by writing "[...] define the `POSIXLY_CORRECT' 
environment variable to a non-null value".

Thank you,

Konrad Schwarz

Siemens AG
Corporate Technology
Software & Engineering / Architecture
CT SE 25
Otto-Hahn-Ring 6
80200 München
Tel.: +49 (89) 636-53579
Fax: +49 (89) 636-45450
Mobile: +49 (170) 9424351
mailto:konrad.schw...@siemens.com
http://www.ct.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Peter Loescher, Chairman, President and Chief Executive 
Officer; Wolfgang Dehen, Heinrich Hiesinger, Joe Kaeser, Erich R. Reinhardt, 
Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered offices: 
Berlin and Munich; Commercial registries: Berlin Charlottenburg, HRB 12300, 
Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

FW: +N option in tail command

[נחשון ישורון/Nachshon Yeshurun]

Hello

Man pages for the tail command shows the ability to use the +N option.
Yet, attempting it on Ubuntu 9.10 results in an error.
Is this a bug?

>From man pages:

  -n, --lines=N
  output the last N lines, instead of the last 10; or  use  +N  to
  output lines starting with the Nth


Attempting the command:

nachs...@nachshon-ubuntu-vm:~/temp$ tail +5 /etc/passwd
tail: cannot open `+5' for reading: No such file or directory
==> /etc/passwd <==
avahi-autoipd:x:104:110:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false
avahi:x:105:111:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
couchdb:x:106:113:CouchDB Administrator,,,:/var/lib/couchdb:/bin/bash
haldaemon:x:107:114:Hardware abstraction layer,,,:/var/run/hald:/bin/false
speech-dispatcher:x:108:29:Speech 
Dispatcher,,,:/var/run/speech-dispatcher:/bin/sh
kernoops:x:109:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false
saned:x:110:116::/home/saned:/bin/false
pulse:x:111:117:PulseAudio daemon,,,:/var/run/pulse:/bin/false
gdm:x:112:119:Gnome Display Manager:/var/lib/gdm:/bin/false
nachshon:x:1000:1000:Nachshon,,,:/home/nachshon:/bin/bash

Re: package url

[Jim Meyering]

Pádraig Brady wrote:
> Eric Blake wrote:
>> Since autoconf 2.64 is now stable, and you have used it (or newer) for the 
>> past
>> couple of releases/snapshots, any objection to this patch?
>
> Too soon IMHO.
> My F11 is on 2.63 for example.

I agree that it's too soon for something that's not a bug fix.
Perhaps at the end of 2010.