bug#65674: (no subject)

[Agostino Sarubbo]

Hello Bruno

thanks for the fast response and for the update suggestion.

Atm we are at openssl-3, but this bug was discovered by 
chance, because a package I was testing forced the downgrade 
to openssl-1

Agostino

bug#34968: (no subject)

[Assaf Gordon]

tags 34968 notabug
close 34968
stop

On 2019-03-24 9:12 a.m., Bernhard Voelker wrote:

I don't know Dutch, but this looks to me like the regular output of "sha256sum 
--help"
from an older version of coreutils (<8.25, because the --ignore-missing option
is not yet there).  What is wrong with it?


With no further replies, I'm closing this bug.

-assaf

bug#34968: (no subject)

[Bernhard Voelker]

tags 34968 moreinfo
stop

On 3/24/19 1:52 AM, catherine & andré wrote:
> Gebruik:  sha256sum [OPTIE] [BESTAND...]
> 
> SHA256-controlesommen (256-bits) tonen of controleren.
> 
> Zonder BESTAND, of wanneer BESTAND - is, wordt standaardinvoer gelezen.
> 
>    -b, --binary    in binaire modus lezen
>    -c, --check SHA256-controlesommen uit BESTAND(en) lezen en 
> controleren
>    --tag   een controlesom in BSD-stijl genereren
>    -t, --text  in tekstmodus lezen (standaard)
> 
> De volgende drie opties gelden alleen bij het controleren van 
> controlesommen:
>    --quiet geen 'goed' tonen voor elk met succes gecontroleerd 
> bestand
>    --status    niets naar de uitvoer sturen; de afsluitwaarde toont 
> succes
>    -w, --warn  waarschuwen bij verkeerd opgemaakte controlesomregels
> 
>    --strict    met '--check': met foutcode afsluiten bij ongeldige 
> invoer
>    --help  deze hulptekst tonen en stoppen
>    --version   programmaversie tonen en stoppen
> 
> De sommen worden berekend zoals beschreven in FIPS-180-2.  Bij het 
> controleren
> moet de invoer voormalige uitvoer van dit programma zijn.  De standaardmodus
> toont voor elk BESTAND een regel met een controlesom, een teken dat het type
> aangeeft ('*' voor binair, ' ' voor tekst), en de naam van het bestand.
> 
> Rapporteer gebreken in 'sha256sum' aan .
> Webpagina van GNU coreutils: 
> Algemene hulp bij gebruik van GNU-software: 
> Meld vertalingsfouten in 'sha256sum' aan .
> Voor volledige documentatie, gebruik:  info coreutils 'sha256sum invocation'

I don't know Dutch, but this looks to me like the regular output of "sha256sum 
--help"
from an older version of coreutils (<8.25, because the --ignore-missing option
is not yet there).  What is wrong with it?

Have a nice day,
Berny

bug#34968: (no subject)

[catherine & andré]

Gebruik:  sha256sum [OPTIE] [BESTAND...]

SHA256-controlesommen (256-bits) tonen of controleren.

Zonder BESTAND, of wanneer BESTAND - is, wordt standaardinvoer gelezen.

  -b, --binary    in binaire modus lezen
  -c, --check SHA256-controlesommen uit BESTAND(en) lezen en 
controleren

  --tag   een controlesom in BSD-stijl genereren
  -t, --text  in tekstmodus lezen (standaard)

De volgende drie opties gelden alleen bij het controleren van 
controlesommen:
  --quiet geen 'goed' tonen voor elk met succes gecontroleerd 
bestand
  --status    niets naar de uitvoer sturen; de afsluitwaarde toont 
succes

  -w, --warn  waarschuwen bij verkeerd opgemaakte controlesomregels

  --strict    met '--check': met foutcode afsluiten bij ongeldige 
invoer

  --help  deze hulptekst tonen en stoppen
  --version   programmaversie tonen en stoppen

De sommen worden berekend zoals beschreven in FIPS-180-2.  Bij het 
controleren

moet de invoer voormalige uitvoer van dit programma zijn.  De standaardmodus
toont voor elk BESTAND een regel met een controlesom, een teken dat het type
aangeeft ('*' voor binair, ' ' voor tekst), en de naam van het bestand.

Rapporteer gebreken in 'sha256sum' aan .
Webpagina van GNU coreutils: 
Algemene hulp bij gebruik van GNU-software: 
Meld vertalingsfouten in 'sha256sum' aan .
Voor volledige documentatie, gebruik:  info coreutils 'sha256sum invocation'

bug#18949: (no subject)

[Assaf Gordon]

tags 18949 fixed
close 18949
stop

(triaging old bugs)

Hello,

Philippe Rassek wrote:

when running for example seq 1 0 10 it will go into an endless loop.

Imho the 2nd parameter (Increment Statement) should be checked for >
0 (greater then 0) before executing.
It seems your email "fell between the cracks" and not replied to in many 
years. Sorry about that.


You suggested have been implemented some time ago, here:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=81e589021d9c47e4fbc4284e82881a9703246476

As such, I'm marking this as "fixed" and closing.

regards,
 - assaf

bug#19681: (no subject)

[Assaf Gordon]

close 19681
stop

Pushed at 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00


closing.

bug#19375: (no subject)

[Assaf Gordon]

tags 19375 fixed
close 19375
stop

pushed at 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=178f8e79dcd1e0b8bbb3b04da664d05eaae56186


closing.

bug#19154: (no subject)

[Assaf Gordon]

tags 19154 fixed
close 19154
stop


Pushed in 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=16e2347bd545057b04a97115563e606ad822ec33


closing.

bug#10493: (no subject)

[Leontiev Danil]

Thx for the answer.

But may be you can specify "target" where to look for bug in kernel and specify 
some "anomiles" while diagnostic\debug?

bug#10493: (no subject)

[Jim Meyering]

Leontiev Danil wrote:
> Log for  "strace -o LOG shred -uvf /media/usb/test" in attachment.
>
> Operation system info:
>
> [root@localhost]$ uname -a
> Linux localhost 2.6.33.7-desktop586-1mnb #1 SMP Fri Aug 27 20:24:16
> UTC 2010 i686 i686 i386 GNU/Linux
>
> [root@localhost]# LANG=C shred --version
> shred (GNU coreutils) 8.5
...

Thanks for the strace log.
It suggests a problem with your file system or the
underlying device, or maybe a kernel bug.

> execve("/usr/bin/shred", ["shred", "-uvf", 
> "/media/netbook-ia32-x86_64-20110"...], [/* 65 vars */]) = 0
> brk(0)  = 0x9385000
...
> open("/media/netbook-ia32-x86_64-201105181448/0", 
> O_WRONLY|O_NOCTTY|O_LARGEFILE) = 3
...
> fcntl64(3, F_SETFL, O_WRONLY|O_DIRECT|O_LARGEFILE) = 0
...
> write(3, 
> "\214~\372\267\214C\230\242,\372\357\333\331\34\257{\327\6{\362\363o\256\212\211\204\242\235\200\265\200\320"...,
>  4096) = 4096
> time(NULL)  = 1326713309
> fdatasync(3)= 0
> _llseek(3, 0, [0], SEEK_SET)= 0
> write(2, "shred: ", 7)  = 7
> write(2, "/media/netbook-ia32-x86_64-20110"..., 71) = 71
> write(2, "\n", 1)   = 1
> time(NULL)  = 1326713309
> write(3, 
> "TI\245\352\217)\3541\f\234\260\272h\330\246{\303\200\317A\372\217\374\21\25\17\376\32\34\320\34N"...,
>  4096) = -1 EINVAL (Invalid argument)

Note how the first 4KiB write succeeds,
yet the second one fails with EINVAL.

shred.c is designed to accommodate (and recover from) an EINVAL failure
when that failure happens on the very first write syscall.  However, when
it happens
after that, the code presumes there really is an error.

For the record, the diagnostic you're seeing is the one from the
end of this excerpt:

  while (true)
{
  /* How much to write this time? */
  lim = sizeof r;
  if (0 <= size && size - offset < sizeof_r)
{
  if (size < offset)
break;
  lim = size - offset;
  if (!lim)
break;
}
  if (type < 0)
randread (s, &r, lim);
  /* Loop to retry partial writes. */
  for (soff = 0; soff < lim; soff += ssize, first_write = false)
{
  ssize = write (fd, r.c + soff, lim - soff);
  if (ssize <= 0)
{
  if (size < 0 && (ssize == 0 || errno == ENOSPC))
{
  /* Ah, we have found the end of the file */
  *sizep = size = offset + soff;
  break;
}
  else
{
  int errnum = errno;
  char buf[INT_BUFSIZE_BOUND (uintmax_t)];

  /* If the first write of the first pass for a given file
 has just failed with EINVAL, turn off direct mode I/O
 and try again.  This works around a bug in Linux kernel
 2.4 whereby opening with O_DIRECT would succeed for some
 file system types (e.g., ext3), but any attempt to
 access a file through the resulting descriptor would
 fail with EINVAL.  */
  if (k == 1 && first_write && errno == EINVAL)
{
  direct_mode (fd, false);
  ssize = 0;
  continue;
}
  error (0, errnum, _("%s: error writing at offset %s"),
 qname, umaxtostr (offset + soff, buf));


If you're ambitious, you can find out if the kernel bug mentioned above
affects 2.6.x and is now triggered only on the *second* write (with 2.4,
it was triggered on the first).  To do that, could change this line in
src/shred.c,

- if (k == 1 && first_write && errno == EINVAL)
+ if (k == 1 && errno == EINVAL)

and build shred from source.

Note however: that induces the risk of an infinite loop.
It will work fine if write fails with EINVAL only on the second
attempt, but then always succeeds after turning off O_DIRECT.

bug#10493: (no subject)

[Leontiev Danil]

Good day.

Sorry for delay.

Log for  "strace -o LOG shred -uvf /media/usb/test" in attachment.



Operation system info:

[root@localhost]$ uname -a
Linux localhost 2.6.33.7-desktop586-1mnb #1 SMP Fri Aug 27 20:24:16 UTC 2010 
i686 i686 i386 GNU/Linux

[root@localhost]# LANG=C shred --version
shred (GNU coreutils) 8.5
Copyright (C) 2010 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 Colin Plumb.





LOG
Description: Binary data

Re: (no subject)

[Kamil Dudka]

On Friday 29 of January 2010 18:11:53 Henry Hung wrote:
> Hi
> I don't know whether this is a design intent or a bug.
> When I tried to list recursively a specified file, ls only searched the
> current directory for the file, not recursively. For example, ls -R myFile*

http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f

Kamil

(no subject)

[Henry Hung]

Hi 
I don't know whether this is a design intent or a bug.
When I tried to list recursively a specified file, ls only searched the current 
directory for the file, not recursively. For example,
ls -R myFile*
displays only files with myFile pattern residing in the current working 
directory but not those in the sub-directories. 
All I want to do is to look for files with certain pattern throughout all 
sub-directories and the paths those files are located. 
ls -R | grep myFile*
works great but it doesn't give me the path of those files.
Is there a easy way to do it? Thanks
Henry 


  __
Ask a question on any topic and get answers from real people. Go to Yahoo! 
Answers and share what you know at http://ca.answers.yahoo.com

firefox problem on Acer (was: (no subject))

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[please use a descriptive subject line, to improve the chance that people
will not discard your mail as spam]

According to lynn and jym on 3/19/2009 4:47 AM:

Hello,

> i have two acer aspires that i can not conect to the internet due to a 
> firefox problem i have been on to acer support since 10th march and still 
> have no joy can you help

If you would be so kind could you tell us what has directed you
to ask your question on this mailing list?  We fear that there may be
incorrect documentation pointing you here.  If you would help us so
that we could improve the directions it would help others.  Thanks!

You have reached the GNU Coreutils mailing list.  The GNU Coreutils
are the basic file, shell and text manipulation utilities of the GNU
Operating System.  You can learn more about GNU Coreutils here:

  http://www.gnu.org/software/coreutils/

The GNU Coreutils are part of the GNU Operating System.  You can learn
more about the GNU Project here:

  http://www.gnu.org/

But you are asking about firefox on Acer.  I am sorry but this
is the wrong mailing list. We are unable to help you here.

You may find these links helpful for advice on how to make your future bug
reports more effective:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
http://www.catb.org/~esr/faqs/smart-questions.html

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

iEYEARECAAYFAknCOU8ACgkQ84KuGfSFAYCyOwCgunQUnSzy7dEnos968QvEWWlP
8roAoL3BlC/CRYf3lOajEAdFcImKVt51
=eHe5
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[lynn and jym]

i have two acer aspires that i can not conect to the internet due to a firefox 
problem i have been on to acer support since 10th march and still have no joy 
can you help
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Pádraig Brady]

Jeromy Keloway wrote:
> Good afternoon
> 
> What I have to say is a little bit... hard to believe.
> But I think I found a "bug" in the Shell-Command "cp". The command goes into 
> a endless loop when I do the following:
> 
> 
> 1) Mount a partition with the filesystem "ext3" ("/media/EXT3drive")
> 
> 2) Mount a partition with the filesystem "fat32" ("/media/FAT32drive")
> 
> 3) Generate a file on the ext3-System with a filesize > 4GB
> 
> 4) Try to copy this file from /media/EXT3drive to /media/FAT32drive with the 
> following command: "cp -urv /media/EXT3drive/4GBfile.img 
> /media/FAT32drive/4GBfile.img"
> 
> 5) The file will be transfered until the filesize reached the 4GB limit. When 
> the file has the maximum size that is possible on FAT32, it stop growing and 
> cp is waiting forever to complet this file(wait about 48h -> nothing happens).
> 
> 
> What cp should do:
> 
> Check the filesystem on the target partition before the transfer begins and 
> inform the user about any problems OR interrupt the transfer of this file and 
> write a log/inform the user.
> 
> Thanks for your attention
> 
> Jeromy

Seems fine here:

$ truncate -s5GB /media/disk/5GBfile.img
truncate: truncating `/media/disk/5GBfile.img' at 50 bytes: File too 
large
$ ls -l /media/disk/5GBfile.img
-rwxr-xr-x 1 padraig root 0 2009-02-04 11:01 /media/disk/5GBfile.img
$ rm /media/disk/5GBfile.img

$ truncate -s5GB 5GBfile.img
$ cp -urv 5GBfile.img /media/disk/
`5GBfile.img' -> `/media/disk/5GBfile.img'
cp: cannot lseek `/media/disk/5GBfile.img': Invalid argument
$ rm /media/disk/5GBfile.img

$ cp --sparse=never -urv 5GBfile.img /media/disk/
`5GBfile.img' -> `/media/disk/5GBfile.img'
./cp: writing `/media/disk/5GBfile.img': File too large
$ ls -l /media/disk/5GBfile.img
-rwxr-xr-x 1 padraig root 4,294,967,295 2009-02-04 11:14 /media/disk/5GBfile.img

What version of kernel and coreutils do you have?
I would guess that the FAT driver in your kernel may be having issues?

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Kamil Dudka]

On Tuesday 03 February 2009 17:01:02 Jeromy Keloway wrote:
> Good afternoon
>
> What I have to say is a little bit... hard to believe.
> But I think I found a "bug" in the Shell-Command "cp". The command goes
> into a endless loop when I do the following:
Endless loop? Does the cp process consume CPU or it is suspended on I/O 
operation by kernel?

> 1) Mount a partition with the filesystem "ext3" ("/media/EXT3drive")
>
> 2) Mount a partition with the filesystem "fat32" ("/media/FAT32drive")
>
> 3) Generate a file on the ext3-System with a filesize > 4GB
>
> 4) Try to copy this file from /media/EXT3drive to /media/FAT32drive with
> the following command: "cp -urv /media/EXT3drive/4GBfile.img
> /media/FAT32drive/4GBfile.img"
>
> 5) The file will be transfered until the filesize reached the 4GB limit.
> When the file has the maximum size that is possible on FAT32, it stop
> growing and cp is waiting forever to complet this file(wait about 48h ->
> nothing happens).
Does it happen only with cp or other programs on your system bahave this way? 
Strace output could help in both cases.

> What cp should do:
>
> Check the filesystem on the target partition before the transfer begins and
> inform the user about any problems OR interrupt the transfer of this file
> and write a log/inform the user.
Current cp implementation is file system independent. I am not sure if the 
proposed solution is the clearest one.


Kamil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Jeromy Keloway]

Good afternoon

What I have to say is a little bit... hard to believe.
But I think I found a "bug" in the Shell-Command "cp". The command goes into a 
endless loop when I do the following:


1) Mount a partition with the filesystem "ext3" ("/media/EXT3drive")

2) Mount a partition with the filesystem "fat32" ("/media/FAT32drive")

3) Generate a file on the ext3-System with a filesize > 4GB

4) Try to copy this file from /media/EXT3drive to /media/FAT32drive with the 
following command: "cp -urv /media/EXT3drive/4GBfile.img 
/media/FAT32drive/4GBfile.img"

5) The file will be transfered until the filesize reached the 4GB limit. When 
the file has the maximum size that is possible on FAT32, it stop growing and cp 
is waiting forever to complet this file(wait about 48h -> nothing happens).


What cp should do:

Check the filesystem on the target partition before the transfer begins and 
inform the user about any problems OR interrupt the transfer of this file and 
write a log/inform the user.

Thanks for your attention

Jeromy
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Alfred M. Szmidt]

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

using gpg on Windows (was: (no subject))

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Please use a better subject line, if you want to ensure your mail is not
confused with junk mail]

According to Martin Douglas on 11/29/2008 2:15 PM:
> I think this is what the apache download page says to do to check the 
> signature of the downloaded file
> 
> c:\Users\MyName\Documents>"c:\Program Files\GNU\GnuPG\gpg.exe" --verify 
> apache.asc
> gpg: no signed data
> gpg: can't hash datafile: file open error

You have reached the GNU Coreutils mailing list.  The GNU Coreutils
are the basic file, shell and text manipulation utilities of the GNU
Operating System.  You can learn more about GNU Coreutils here:

  http://www.gnu.org/software/coreutils/

The GNU Coreutils are part of the GNU Operating System.  You can learn
more about the GNU Project here:

  http://www.gnu.org/

But you are asking about gpg.  I am sorry but this is the wrong mailing
list. We are unable to help you here; you will probably have better luck
with the gpg project:

  http://www.gnupg.org/

Meanwhile, it appears that you are asking about a w32 port of gpg;
often-times, you will get more appropriate response for questions about
using GNU software on Windows by asking the people that provide the
precompiled binary that you are using (such as the cygwin or mingw lists).

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkk2HR8ACgkQ84KuGfSFAYCwOgCgpUXj7//jsczSCtFOInYPXqs2
fOIAn0TaEf7etJxTPDaD9G2g/uNfjUR6
=0uxN
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Jan Halla]

@menu
* Overview::Overview
* Hardware::POD, Pins, Power
* Driver::  The Driver
* Library:: A Library for Applications

* Testing:: Is BDM working

* GDB:: Building and using GDB

* Server::  BDM Server

@c Following blank line required for remaining bug in makeinfo conds/menus

* Reporting Bugs::  Reporting Bugs
* Index::   Index
@end menu
@end ifinfo

@c ---
@node Overview, Build System, Top, Top
@chapter Overview

@cindex what is this?

Welcome to Background Debug Mode (BDM) support for GDB. BDM is emulator
or debugger support in a range of Motorola processors. This package
deals with the CPU32, and Coldfire family of processors. PowerPC
processors are not supported by this package. 

CPU32 processors were the first processors to appear with BDM
support. The Coldfire family's BDM module is similar to the CPU32 family
of processors. The CPU32 has the BDM module integrated into the
processor core. The Coldfire is more modular. The debug module is
separate to the core.

BDM is not JTAG debugging although a serial bug is used. JTAG is a
standard and operates differently to BDM. BDM uses high level commands
to control the device. You do not need to clock in and out a loop of
registers.

BDM is accessed on the procesor via a three wire serial bus. The signals
are a clock, data in and data out. Various other support signals
exists. This are used to place the processor into BDM, break the
prcessor, or monitor the status of a running processor.

The CPU32 standard BDM connector is not the same as the Coldfire
connector. You need separate plug on modules for each processor
family. Check the POD you use matches the processors voltage and clock
speed. This is import for Coldfire users.

Coldfire BDM has support for realtime trace. This package does not
support realtime trace.

Coldfire BDM can operate in a limited manner while the processor is
running. The BDM module being separate from the procesor core allows
this feature.

History

Gunta Magna contributes here is a bit of history of how GDB and BDM
came to light due to mutual support.

Somewhere in 1994/1995 Gunta Magna wrote (with the help of Michael
Schraut, at that time a student at lpr.e-technik.tu-muenchen) a first
version of the m68k Linux BDM device driver. This driver heavily based
on the work of Scott Howard ([EMAIL PROTECTED]), who wrote BD32, a DOS
tool to access 683xx controllers via BDM. He made the driver available
in source form, so I could use them.  Scott is currently maintainer of
the crossgcc mailing list (http://www.objsw.com/CrossGCC/).

Additionally Gunta Magna wrote a BDM backend for gdb-4.13. (Note: Eric
credits M.Schraut falsly as the author of the GDB patches in the header
files. This went through until Chris Johns's version for Coldfire).

The driver was only for BDM interfaces compatilble to AN1230, aka as PD
interfaces. Scott supported also the ICD compatible interface, but due to
lack of equipment at that time Gunta Magna did not include that.

Eric Norum used those sources to port it to NextStep. He did not like
my way of interfacing driver and application, and designed a new
interface. He also introduced an abstraction layer, enabling other
applications than gdb to take advantage of the BDM driver. He also added
support for 68360, which is different in detail from the 68332 version
(MBAR support).

In 1996, Gunta Magna upgraded his driver to ICD by a compile time
option, and fixed some errors. He also upgraded the gdb backend to
gdb-4.16, introducing Eric's idea of the abstraction layer. Sources for
that can be found at the ftp server of lpr.e-technik.tu-muechen.de

In 1997 Eric went Linux and ported his NextStep driver to Linux. He
also wrote/ported his NextStep gdb backend, incorporating some of the
ideas (and bugs) introduced in Gunta's 4.16-version. He also published a
schematic stemming from the Motorola customer center here in Munich
(bd32new) (See below).

In 1997 I upgraded my driver to simultaneously support ICD and PD
interfaces. The selection is made by accessing different minor numbers.
This version has been handed out to several testers (including Chris
Johns), but has never been officially released.

Chris Johns used Eric's driver and added Coldfire support.

@c ---
@node Build System, Layout, Overview, Top
@chapter POD, Pins, Power

@cindex hardware

Various means exist to access a BDM port on a processor. This driver
provides support for various host operating system, and adapator boards.

The driver support the IDC hardware. A circuit abd PAL equations are
provided in the package.

The Coldfire support is via the P&E standard interface. You can find
information about these adaptor from the P&E web site.



Coldfire

The Coldfire has a 26pin header. The expanded connector 

(no subject)

[Martin Douglas]

I think this is what the apache download page says to do to check the signature 
of the downloaded file

c:\Users\MyName\Documents>"c:\Program Files\GNU\GnuPG\gpg.exe" --verify 
apache.asc
gpg: no signed data
gpg: can't hash datafile: file open error

That did not work so well...SOOO...

This is what I did... Does this output mean everything is ok? It seems mostly 
ok... 

c:\Users\MyName\Documents>"c:\Program Files\GNU\GnuPG\gpg.exe" --verify 
apache.asc c:\Users\MyName\Desktop\apache-ant-1.7.1-bin.zip
gpg: Signature made 06/27/08 00:50:34 using DSA key ID AA0077B0
gpg: Good signature from "Kev Jackson (apache key) <[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: F54C 925C 2454 F21D 8669  2540 A0BF F93D AA00 
77B0___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[James Youngman]

On Thu, Jul 3, 2008 at 11:48 PM, Craig Naumann <[EMAIL PROTECTED]> wrote:
> hello, i cant use the "ls" command in cygwin, it says command not found.

You should ask about your problem on the Cygwin mailing list.

Thanks,
James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Craig Naumann]

hello, i cant use the "ls" command in cygwin, it says command not found.


  



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Erik Auerswald]

>From 0bd30949c1953fc5339fc5cf30cc2527d3e660d7 Mon Sep 17 00:00:00 2001
From: Erik Auerswald <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 18:12:11 +0200
Subject: [PATCH] md5sum+sha*sum: add option --quiet/-q to suppress OK messages

* src/md5sum.c: add option --quiet/-q to suppress OK messages
* doc/coreutils.texi: document option --quiet/-q
* tests/misc/md5sum: add test for option --quiet/-q
* NEWS: mention new option --quiet/-q for md5sum+sha*sum in "New
  features" section

Signed-off-by: Erik Auerswald <[EMAIL PROTECTED]>
---
 NEWS   |3 +++
 doc/coreutils.texi |   11 +++
 src/md5sum.c   |   29 +
 tests/misc/md5sum  |8 
 4 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index e208b30..5a97f13 100644
--- a/NEWS
+++ b/NEWS
@@ -47,6 +47,9 @@ GNU coreutils NEWS-*- 
outline -*-
 
 ** New features
 
+  md5sum and sha*sum now know an option --quiet/-q to suppress the
+  printing of 'OK' messages.
+
   join now verifies that the inputs are in sorted order.  This check can
   be turned off with the --nocheck-order option.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 01c2f00..7bffd34 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3287,6 +3287,17 @@ If all listed files are readable and are consistent with 
the associated
 MD5 checksums, exit successfully.  Otherwise exit with a status code
 indicating there was a failure.
 
[EMAIL PROTECTED] -q
[EMAIL PROTECTED] --quiet
[EMAIL PROTECTED] -q
[EMAIL PROTECTED] --quiet
[EMAIL PROTECTED] verifying MD5 checksums
+This option is useful only when verifying checksums.
+When verifying checksums, don't generate an 'OK' message per successfully
+checked file. Files that fail the verification are reported in the
+default one-line-per-file format. If any files failed verification,
+a warning summarizing any failures is printed to standard error.
+
 @item -t
 @itemx --text
 @opindex -t
diff --git a/src/md5sum.c b/src/md5sum.c
index 28bde99..821a3ad 100644
--- a/src/md5sum.c
+++ b/src/md5sum.c
@@ -114,6 +114,9 @@ static bool status_only = false;
improperly formatted checksum line.  */
 static bool warn = false;
 
+/* With --quiet, don't print a message for successfully verified files */
+static bool quiet = false;
+
 /* The name this program was run with.  */
 char *program_name;
 
@@ -131,6 +134,7 @@ static const struct option long_options[] =
   { "status", no_argument, NULL, STATUS_OPTION },
   { "text", no_argument, NULL, 't' },
   { "warn", no_argument, NULL, 'w' },
+  { "quiet", no_argument, NULL, 'q' },
   { GETOPT_HELP_OPTION_DECL },
   { GETOPT_VERSION_OPTION_DECL },
   { NULL, 0, NULL, 0 }
@@ -174,8 +178,9 @@ With no FILE, or when FILE is -, read standard input.\n\
 "), stdout);
   fputs (_("\
 \n\
-The following two options are useful only when verifying checksums:\n\
+The following three options are useful only when verifying checksums:\n\
   --statusdon't output anything, status code shows success\n\
+  -q, --quiet no output for successfully verified files\n\
   -w, --warn  warn about improperly formatted checksum lines\n\
 \n\
 "), stdout);
@@ -521,8 +526,10 @@ digest_check (const char *checkfile_name)
 
  if (!status_only)
{
- printf ("%s: %s\n", filename,
- (cnt != digest_bin_bytes ? _("FAILED") : _("OK")));
+ if (cnt != digest_bin_bytes)
+   printf ("%s: %s\n", filename, _("FAILED"));
+ else if (!quiet)
+   printf ("%s: %s\n", filename, _("OK"));
  fflush (stdout);
}
}
@@ -603,7 +610,7 @@ main (int argc, char **argv)
 
   atexit (close_stdout);
 
-  while ((opt = getopt_long (argc, argv, "bctw", long_options, NULL)) != -1)
+  while ((opt = getopt_long (argc, argv, "bctwq", long_options, NULL)) != -1)
 switch (opt)
   {
   case 'b':
@@ -615,6 +622,7 @@ main (int argc, char **argv)
   case STATUS_OPTION:
status_only = true;
warn = false;
+   quiet = false;
break;
   case 't':
binary = 0;
@@ -622,6 +630,12 @@ main (int argc, char **argv)
   case 'w':
status_only = false;
warn = true;
+   quiet = false;
+   break;
+  case 'q':
+   status_only = false;
+   warn = false;
+   quiet = true;
break;
   case_GETOPT_HELP_CHAR;
   case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);
@@ -653,6 +667,13 @@ main (int argc, char **argv)
   usage (EXIT_FAILURE);
 }
 
+  if (quiet & !do_check)
+{
+  error (0, 0,
+   _("the --quiet option is meaningful only when verifying checksums"));
+  usage (EXIT_FAILURE);
+}
+
   if (!O_BINARY && binary < 0)
 binary = 0;
 
diff --git a/tests/misc/md5sum b/tests/misc/md5sum
index ca23d94..da58801 100755
--- a/tests/misc/md5sum
+

Re: (no subject)

[James Youngman]

Sorry, that was a duplicate patch, badly formatted.   Apologies.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[James Youngman]

>From d3ffc5547f1d77131ebdd4641c422072f2743283 Mon Sep 17 00:00:00 2001
From: James Youngman <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 15:43:56 +
Subject: [PATCH] Implement join --check-order.

2008-02-16  James Youngman  <[EMAIL PROTECTED]>

* src/join.c (join): Support --check-order and --nocheck-order.
For --check-order, verify that the input files are in sorted
order.
(usage): Mention --check-order and --nocheck-order.
(dupline): Save a copy of the previously-read input line so that
we can detect disorder on the input.
(get_line): Temporarily save a copy of the previous line (by
calling dupline) and check relative ordering (by calling
checkorder) before returning the newly-read line.
(getseq, join): Tell get_line which file we are reading from.
(advance_seq): New function, factoring out some of the code
commonly surrounding calls to getseq.
(checkorder): New function.  Verifies that a pair of consecutive
input lines are in sorted order.
* coreutils.texi (join invocation): Document the new options
--check-order and --nocheck-order.
---
 doc/coreutils.texi |   19 ++-
 src/join.c |  129 ++-
 2 files changed, 122 insertions(+), 26 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 23d0ab4..0dd4587 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,9 +5149,16 @@ sort a file on its default join field, but if you select 
a non-default
 locale, join field, separator, or comparison options, then you should
 do so consistently between @command{join} and @command{sort}.
 
-As a @acronym{GNU} extension, if the input has no unpairable lines the
-sort order can be any order that considers two fields to be equal if and
-only if the sort comparison described above considers them to be equal.
[EMAIL PROTECTED] Unsorted inputs are a common cause of FAQs, but we probably 
[EMAIL PROTECTED] should not make --check-order the default, as we documented 
this
[EMAIL PROTECTED] extension and so should continue to allow it
+.
+If the @option{--check-order} option is given, unsorted inputs will
+cause a fatal error message.  If the @option{--check-order} option is
+not given, a @acronym{GNU} extension is available: if the input has no
+unpairable lines the sort order can be any order that considers two
+fields to be equal if and only if the sort comparison described above
+considers them to be equal.
 For example:
 
 @example
@@ -5188,6 +5195,12 @@ The program accepts the following options.  Also see 
@ref{Common options}.
 Print a line for each unpairable line in file @var{file-number} (either
 @samp{1} or @samp{2}), in addition to the normal output.
 
[EMAIL PROTECTED] --check-order
+Check that both input files are in sorted order.
+
[EMAIL PROTECTED] --nocheck-order
+Do not check that both input files are in sorted order.  This is the default.
+
 @item -e @var{string}
 @opindex -e
 Replace those output fields that are missing in the input with
diff --git a/src/join.c b/src/join.c
index a6ca7e4..2a5147d 100644
--- a/src/join.c
+++ b/src/join.c
@@ -108,9 +108,21 @@ static struct outlist *outlist_end = &outlist_head;
tab character whose value (when cast to unsigned char) equals TAB.  */
 static int tab = -1;
 
+/* If nonzero, check that the input is correctly ordered. */
+static bool check_input_order = false;
+
+enum
+{
+  CHECK_ORDER_OPTION = CHAR_MAX + 1, 
+  NOCHECK_ORDER_OPTION
+};
+
+ 
 static struct option const longopts[] =
 {
   {"ignore-case", no_argument, NULL, 'i'},
+  {"check-order", no_argument, NULL, CHECK_ORDER_OPTION},
+  {"nocheck-order", no_argument, NULL, NOCHECK_ORDER_OPTION},
   {GETOPT_HELP_OPTION_DECL},
   {GETOPT_VERSION_OPTION_DECL},
   {NULL, 0, NULL, 0}
@@ -122,6 +134,9 @@ static struct line uni_blank;
 /* If nonzero, ignore case when comparing join fields.  */
 static bool ignore_case;
 
+
+static void checkorder (const struct line *, const struct line *, int);
+
 void
 usage (int status)
 {
@@ -153,6 +168,8 @@ by whitespace.  When FILE1 or FILE2 (not both) is -, read 
standard input.\n\
   -v FILENUMlike -a FILENUM, but suppress joined output lines\n\
   -1 FIELD  join on this FIELD of file 1\n\
   -2 FIELD  join on this FIELD of file 2\n\
+  --check-order check that the input is correctly sorted\n\
+  --nocheck-order   do not check that the input is correctly sorted\n\
 "), stdout);
   fputs (HELP_OPTION_DESCRIPTION, stdout);
   fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -228,12 +245,49 @@ xfields (struct line *line)
   extract_field (line, ptr, lim - ptr);
 }
 
+struct line*
+dupline (const struct line *old)
+{
+  struct line *newline = xmalloc (sizeof *newline);
+  size_t i;
+  
+  /* Duplicate the buffer. */
+  initbuffer (&newline->buf);
+  newline->buf.buffer = xmalloc (old->buf.size);
+  newline->buf.size = old->buf.size;
+

Re: df reporting and removing files (Re: (no subject))

[John Cowan]

Elmian Shabahang scripsit:

> as I get , some processes are still blocking the file. How can I find and
> kill them? 

There is no portable way.  However, if your system provides the
"lsof" command, you can use that to discover the files currently
open and the processes that hold them open.

-- 
John Cowan   [EMAIL PROTECTED]
"Mr. Lane, if you ever wish anything that I can do, all you will have
to do will be to send me a telegram asking and it will be done."
"Mr. Hearst, if you ever get a telegram from me asking you to do
anything, you can put the telegram down as a forgery."


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

RE: df reporting and removing files (Re: (no subject))

[Elmian Shabahang]

Hello ,

Thanks for your complete and helpful explanation. 

I would be thankful if you could help me with following question.

as I get , some processes are still blocking the file. How can I find and
kill them? 

 

Best regards,

Elmian,

 

 

-Original Message-
From: Bob Proulx [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 17, 2007 8:01 PM
To: Elmian Shabahang
Cc: bug-coreutils@gnu.org
Subject: df reporting and removing files (Re: (no subject))

 

Elmian Shabahang wrote:

> Hello,

 

In the future please include a meaningful subject line otherwise it is

likely that your message will be deleted without reading because it

looks too much like spam.

 

> Please find following information:

> /dev/vg00/lvol8   8.7G  7.7G  619M  93% /u01

> 

> [EMAIL PROTECTED] u01]$ du -lkhs /u01

> 5.5G/u01

 

You appear to be concerned that df reports 7.7G used but du does not

find it by traversing the filesystem?  Is that correct?

 

> Note that I have deleted a 2.2 GB file , and du don't update the output

> table.

 

That is perfectly okay.  The 'df' command reports information about

filesystem.  The 'du' command traverses directories and reports

information in directory hierarchies.  Those are two different things

and they may report different information.  In this case it means that

disk space is in use by processes but is not reachable by the

directory hierarchy.  Since you said that you removed the file from

the directory this information is verified.

 

The filesystem recovers disk space through garbage collection.  When

files are busy the disk space is in use.  When the reference count for

a file is reduced to zero then the filesystem recovers the disk blocks

associated with the file.

 

Removing files removes the directory pointer to that file but it does

not remove the file from use by running processes.  If a running

process has the file open then the reference count will be non-zero

due to use by that process and the filesystem will not be able to

reclaim that disk space until the process exits.

 

A typical example is a program writing a log file.  The log file may

grow to be quite large.  As long as the process is running the

reference count for that file will be non-zero.  Removing the file

from the directory will not free up the disk space.  In fact doing so

means that there is no no way to access that file again.  The only way

to reduce the reference count would be to kill the process that holds

the file in use.  To avoid this case it is better to truncate large

files to free up the disk space immediately instead of removing them.

 

Hope that helps.

 

Bob

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

df reporting and removing files (Re: (no subject))

[Bob Proulx]

Elmian Shabahang wrote:
> Hello,

In the future please include a meaningful subject line otherwise it is
likely that your message will be deleted without reading because it
looks too much like spam.

> Please find following information:
> /dev/vg00/lvol8   8.7G  7.7G  619M  93% /u01
> 
> [EMAIL PROTECTED] u01]$ du -lkhs /u01
> 5.5G/u01

You appear to be concerned that df reports 7.7G used but du does not
find it by traversing the filesystem?  Is that correct?

> Note that I have deleted a 2.2 GB file , and du don't update the output
> table.

That is perfectly okay.  The 'df' command reports information about
filesystem.  The 'du' command traverses directories and reports
information in directory hierarchies.  Those are two different things
and they may report different information.  In this case it means that
disk space is in use by processes but is not reachable by the
directory hierarchy.  Since you said that you removed the file from
the directory this information is verified.

The filesystem recovers disk space through garbage collection.  When
files are busy the disk space is in use.  When the reference count for
a file is reduced to zero then the filesystem recovers the disk blocks
associated with the file.

Removing files removes the directory pointer to that file but it does
not remove the file from use by running processes.  If a running
process has the file open then the reference count will be non-zero
due to use by that process and the filesystem will not be able to
reclaim that disk space until the process exits.

A typical example is a program writing a log file.  The log file may
grow to be quite large.  As long as the process is running the
reference count for that file will be non-zero.  Removing the file
from the directory will not free up the disk space.  In fact doing so
means that there is no no way to access that file again.  The only way
to reduce the reference count would be to kill the process that holds
the file in use.  To avoid this case it is better to truncate large
files to free up the disk space immediately instead of removing them.

Hope that helps.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Elmian Shabahang]

Hello,

Please find following information:

 

[EMAIL PROTECTED] u01]$ df -lkh

FilesystemSize  Used Avail Use% Mounted on

/dev/vg00/lvol0   6.8G  347M  6.1G   6% /

/dev/cciss/c0d0p1  97M   17M   76M  18% /boot

none  1.8G 0  1.8G   0% /dev/shm

/dev/vg00/lvol2   2.9G  785M  2.0G  28% /tmp

/dev/vg00/lvol8   8.7G  7.7G  619M  93% /u01

/dev/vg00/lvol929G   23G  4.9G  83% /u02

/dev/vg00/lvol1   3.9G  2.6G  1.1G  71% /usr

/dev/vg00/lvol3   2.0G  240M  1.6G  13% /var

/dev/cciss/c0d167G   60G  4.4G  94% /backup

[EMAIL PROTECTED] u01]$ du -lkhs /u01

5.5G/u01

[EMAIL PROTECTED] u01]$ man df

[EMAIL PROTECTED] u01]$ uname -a

Linux dbapp032 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686 i686
i386 GNU/Linux

[EMAIL PROTECTED] u01]$

 

Note that I have deleted a 2.2 GB file , and du don't update the output
table.

 

Best regards,

shabahang

 

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sort bizard behavior [was: (no subject)]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to ara on 4/2/2007 2:59 PM:
> Subject: sort bizard behavior

Your mailer did not format the subject line properly.

> 
> Please read the following. I do not know if it should be like that
> 
> 
> [EMAIL PROTECTED]:~> export LANG=en_US.UTF-8
> [EMAIL PROTECTED]:~> sort < s2
> 10 sfdafdsafdsa
> 1 safdfdsafsd
> 22
> [EMAIL PROTECTED]:~> unset LANG
> [EMAIL PROTECTED]:~> sort < s2
> 1 safdfdsafsd
> 10 sfdafdsafdsa
> 22

Yes, that is correct.  LANG controls the default setting of LC_COLLATE
(which can also be controlled by LC_ALL); setting any one of these three
environment variables to anything other than C (or POSIX) means that you
want strcoll to obey locale sorting rules.  And the en_US.UTF-8 locale
intentionally does not sort by byte order in strcoll.
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEbIJ84KuGfSFAYARAlihAKCGjmz24wpF6pphkJD0X2TS0jhM2QCfVxFy
8SWbf7xuY6Gn439/KuswN3I=
=sldv
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[ara]

Subject: sort bizard behavior

Please read the following. I do not know if it should be like that


[EMAIL PROTECTED]:~> export LANG=en_US.UTF-8
[EMAIL PROTECTED]:~> cat s2
10 sfdafdsafdsa
1 safdfdsafsd
22
[EMAIL PROTECTED]:~> sort < s2
10 sfdafdsafdsa
1 safdfdsafsd
22
[EMAIL PROTECTED]:~> unset LANG
[EMAIL PROTECTED]:~> sort < s2
1 safdfdsafsd
10 sfdafdsafdsa
22
[EMAIL PROTECTED]:~> 


Thanks



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[James Youngman]

(coreutils mailing list moved to BCC)

On 2/6/07, Dima Abramian <[EMAIL PROTECTED]> wrote:

My computer has deteriorated:

/dev/sda2: UNEXPECTED INCONSISTENCY: RUN fsck MANUALY.
(i.e., without -a or -p options)


Please help, thanks



Sorry, we don't do general support of Linux here on the bug-coreutils
mailing list.  We just support the tools in the coureutils package
(for example "ls", "cat" and so forth).   You might have better luck
asking on a generic Linux support mailing list, or asking at your
local Linux Users' Group, or contacting the supplier of your Linux
distribution for support, or reading the documentation for fsck a bit
more.

But, did you notice that the fsck error message that you quoted
suggests what you might need to do?

James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: disk corruption [Was: (no subject)]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please use an informative subject line; otherwise your mail is likely to
be eaten by spam filters.

According to Dima Abramian on 2/6/2007 2:29 AM:
> My computer has deteriorated:
> 
> /dev/sda2: UNEXPECTED INCONSISTENCY: RUN fsck MANUALY.
> (i.e., without -a or -p options)

Unfortunately, the coreutils mailing list is unable to help you with this
issue.  Have you tried running 'fsck' as directed?  But other than that,
it is not really the fault of coreutils, nor something that coreutils can
clean up.

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFyIZ184KuGfSFAYARAu5HAJ9g6B0ZoseEgxiXGALDt+xLRoWbFgCeLRnE
zxxzeCkjCB9ZWw+bHcY3rcQ=
=xwih
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Dima Abramian]

My computer has deteriorated:

/dev/sda2: UNEXPECTED INCONSISTENCY: RUN fsck MANUALY.
(i.e., without -a or -p options)


Please help, thanks
 


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Andreas Schwab]

[EMAIL PROTECTED] writes:

> A very odd bug, when a call the comand:
> date --date="2006-10-15"
> this give me a invalid date.
>
> This happens only in that specific date 2006-10-15, very strange. Look
> below.
>
> cged057:~$ date --date="2004-02-27"
> Fri Feb 27 00:00:00 BRT 2004
> cged057:~$ date --date="2006-10-15"
> date: invalid date `2006-10-15'

Brazil usually switches DST on midnight, so it is possible that this point
of time does not exist if it happens to fall on a DST transition.  Now
Brazil has recently changed its DST rules that makes this point of time
valid again, but you still have this problem with other dates like
2005-10-16 00:00.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[newtonjunior]

A very odd bug, when a call the comand:
date --date="2006-10-15"
this give me a invalid date.

This happens only in that specific date 2006-10-15, very strange. Look
below.

cged057:~$ date --date="2004-02-27"
Fri Feb 27 00:00:00 BRT 2004
cged057:~$ date --date="2006-10-15"
date: invalid date `2006-10-15'
cged057:~$ date --date="2006-10-14"
Sat Oct 14 00:00:00 BRT 2006
cged057:~$ date --date="20061014"
Sat Oct 14 00:00:00 BRT 2006
cged057:~$ date --date="20061015"
date: invalid date `20061015'
cged057:~$ date --date="2006-10-15"
date: invalid date `2006-10-15'
cged057:~$ date --date="2006-10-14"
Sat Oct 14 00:00:00 BRT 2006
cged057:~$

I try others dates too, but aparently, this happens only in 2006-10-15.
This happens in a Pentium IV whit Linux 2.6.8-2-386 i686 GNU/Linux - Debian
Sarge


Thanks


Newton José de Moura Júnior
[EMAIL PROTECTED]

Diretoria de Geociencias - DGC
Coordenação de Geodésica - CGED
Rede Brasileira de Monitoramento Contínuo - RBMC
Av. Brasil, 15.671 - Parada de Lucas - CEP: 21241-051
Rio de Janeiro, RJ - Brasil
Tel: 2142-4929
Fax: 2142-4859
===




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: logical paths (was: (no subject))

[Thomas Schwinge]

Hello!

Not an answer to the question, but it might be interesting nevertheless.


On Sat, Sep 09, 2006 at 12:48:11PM -0600, Bob Proulx wrote:
> Kartik K. Agaram wrote:
> > Does POSIX require that coreutils commands use only physical path rather 
> > than pwd to resolve relative paths? When pwd contains symlinks and we try 
> > to operate upon relative paths that take us outside the symlink, the 
> > effect is often jarring and non-intuitive.
> 
> Symlinks violate some principles of least surprise.  Therefore it is
> no surprise that it is impossible to make all uses of symlinks
> unsurprising.

... at least when using the commonly used implementation / interpretation
of `..'.

,
,
 describes another one:
``Lexical File Names in Plan 9 --- or --- Getting Dot-Dot Right by Rob
Pike''.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

logical paths (was: (no subject))

[Bob Proulx]

Kartik K. Agaram wrote:
> Does POSIX require that coreutils commands use only physical path rather 
> than pwd to resolve relative paths? When pwd contains symlinks and we try 
> to operate upon relative paths that take us outside the symlink, the 
> effect is often jarring and non-intuitive.

Symlinks violate some principles of least surprise.  Therefore it is
no surprise that it is impossible to make all uses of symlinks
unsurprising.

Note that '.' and '..' are real directory entries.  They are not
pseudo entries as some appear to believe.  The shell covers them with
fake entires to change the behavior into logical paths when symlinks
are in use.  But that does not remove the underyling entries.  All
operating system kernel system calls use the real entries.  The fake
entries are an imaginary world created within the process model of
new-style, symlink-aware command shells.

Perl, for example, has no built-in knowledge of the shell's attempt to
create an imaginary world with logical paths.

  cd $HOME
  perl -le 'chdir("/tmp");print $ENV{PWD};'

Because of this any command executed as a child of that process cannot
trust that $PWD contains useful information.  They use the real
information provided by the operating system kernel filesystem
interface.  Perl was handy here but really I could use any program
that is not-the-command-shell as an example here.

The $PWD process environment variable is a construct created by the
command shell.  The chdir(2) operating system call does not modify any
process environment variable.  Keeping those two in sync is not an
operating system function and is never automatic.  It is only done as
a convention by some programs, notably the command shell but very few
others.  When mixing programs with different conventions one will
always be surprisingly different than expected from the other one.

> For example:
>$ mkdir base_dir
>$ cd base_dir
>$ mkdir -p x/y
>$ touch z
>$ ln -s x/y f
>$ cd f
>$ cp ../z .
>cp: cannot stat `../z': No such file or directory
>$ ls ..
>y

Thanks for the nice illustrative test case.

>$ mkdir base_dir
>$ cd base_dir
>$ mkdir -p x/y
>$ touch z
>$ ln -s x/y f

At this point try this and remember the inode numbers.

  ls -ldogi . x x/y
  4618405 drwxr-xr-x  3 120 2006-09-09 12:20 .
  4618387 drwxr-xr-x  3  72 2006-09-09 12:20 x
  4618388 drwxr-xr-x  2  48 2006-09-09 12:20 x/y

>$ cd f

At this point you are in the directory base_dir/x/y and not in f as
you think you are.  You got there by going through the f symlink and
you arrived at x/y.

Try this at that point and look at the inode numbers:

  ls -ldogi . ..
  4618388 drwxr-xr-x  2 48 2006-09-09 12:20 .
  4618387 drwxr-xr-x  3 72 2006-09-09 12:20 ..

Compare the inode numbers of the resulting files and directories with
the ones you saw before.  As you can see you are in the x/y directory
as '.' which matches the x/y inode listed previously.  The inode for
'..' matches the inode for x which is the parent directory.

Usually people go through this process of discovery and then decide
that the imaginary world created by the shell and layered on top of
the physical filesystem is the source of trouble and turn off logical
paths in the shell.  Then after using the system that way for a while
they miss the ability to "back out" of directories they arrived at
through a symlink by using "cd ..".  They then restore the default
shell behavior and live in the imaginary world again.  They have
learned that it is imaginary but also now know the real boundaries of
it and can work around the inconsistencies.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

logical paths [was: (no subject)]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please use a subject line.  It makes it less likely that your message will
be discarded as junk.

According to Kartik K. Agaram on 9/9/2006 6:03 AM:
> Hi,
> 
> I suspect this may have come up on this list before, but a search didn't
> reveal it*.
> 
> Does POSIX require that coreutils commands use only physical path rather
> than pwd to resolve relative paths? When pwd contains symlinks and we
> try to operate upon relative paths that take us outside the symlink, the
> effect is often jarring and non-intuitive.

For many commands, POSIX requires that the utility use the underlying
behavior of many syscalls, and those are required to operate on physical
paths.  However, there is nothing preventing coreutils from adding
additional command-line options that tell tools to interpret $PWD and
behave on relative paths logically.  On the other hand, it is quite easy
to type `pwd`/../z, and get a valid physical path to hand to cp,
regardless of whether $PWD is currently physical or logical, rather than
relying on the semantics of ../z being one way or the other.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAwOr84KuGfSFAYARAoAdAKC4iDg6v/EIciskvog6+lbhNUmGZgCgsavw
Yzt/BusSg6P5zlykVzjDoAA=
=LYLx
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Kartik K. Agaram]

Hi,

I suspect this may have come up on this list before, but a search didn't 
reveal it*.


Does POSIX require that coreutils commands use only physical path rather 
than pwd to resolve relative paths? When pwd contains symlinks and we try 
to operate upon relative paths that take us outside the symlink, the 
effect is often jarring and non-intuitive.


For example:
   $ mkdir base_dir
   $ cd base_dir
   $ mkdir -p x/y
   $ touch z
   $ ln -s x/y f
   $ cd f
   $ cp ../z .
   cp: cannot stat `../z': No such file or directory
   $ ls ..
   y

Related discussion on bug-bash:
  http://thread.gmane.org/gmane.comp.shells.bash.bugs/9273

Thanks,
Kartik

* - The closest I got was this thread:
  http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00073.html


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

determining 64-bit hardware [was: (no subject)]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please use a descriptive subject line; otherwise your mail is more likely
to end up in junk mail filters.

According to deepesh chaudhary on 8/27/2006 5:43 PM:
> hi,
> can you guide me how can i determine that my hardware is 32-bit or 64-bit
> and i am using linux.
> regards

Try "uname -m", and see if the machine it lists is a 32-bit platform or
64-bit platform.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE8t4X84KuGfSFAYARAgRSAJ9Epntfgo91HeOhLePRxkU4adD//ACgllUr
mZuQHgFU0KZ2zWoVkC+ptYg=
=Nqps
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[deepesh chaudhary]

hi,
can you guide me how can i determine that my hardware is 32-bit or 64-bit
and i am using linux.
regards
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Re: (no subject)

[ralf . rabemann]

Hi Bob!


thank you for your help!

Ralf


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to [EMAIL PROTECTED] on 5/24/2006 2:42 PM:
> Hi!
> 
> i started to read the doku of textutils, but i dont understand, how i can use 
> the textutils - have i to install any GNU - software before?

textutils is now part of coreutils, and the latest version is 5.96.  Yes,
you will need to install it before you can use it.  GNU/Linux systems
typically come with coreutils pre-installed, but for other operating
systems, the GNU tools are add-ons.  If you look in the right places, you
can often find pre-compiled binaries for your platform, rather than having
to download the source and compile it yourself (this is particularly true
for Windows, where the typical machine does not include a compiler by
default).

> 
> I like to use the textutil-funktions as a subfunction in a windows shell 
> sript - is ths possible?

Yes.  As Bob pointed out, cygwin is a good example of this (it also
includes a compiler, if you wanted to build coreutils from source).
Another Windows port is that you may be interested in would be mingw32.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdaYl84KuGfSFAYARAtH3AJ9PK2NttV0W9NcKnwv2YPw0tNaTQACfV7Ji
6WeSfHX+eb4RpOi/Ool5n/k=
=X7Ei
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Bob Proulx]

[EMAIL PROTECTED] wrote:
> i started to read the doku of textutils, but i dont understand, how
> i can use the textutils - have i to install any GNU - software
> before?
>
> I like to use the textutil-funktions as a subfunction in a windows
> shell sript - is ths possible?

For use on MS-Windows I recommend that you install the Cygwin toolkit.

  http://www.cygwin.com/

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[ralf . rabemann]

Hi!

i started to read the doku of textutils, but i dont understand, how i can use 
the textutils - have i to install any GNU - software before?

I like to use the textutil-funktions as a subfunction in a windows shell sript 
- is ths possible?

thanks for your answer

kind regards
Ralf Rabemann 


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Brian Dessent]

"Lakkimsetti, Chalapathi G" wrote:

>I want to work on mysql in linux. i have gentoo linux in my system. After 
> i loaded mysql5.0.17, if i want to install the mysql it is giving error "NO 
> file/directory found" eventhough it is having that file.

I don't think anyone on this list has any idea of what you're talking
about.  This list is about coreutils, and has nothing to do with mysql,
gentoo, or general linux questions.  You need to post your question to a
mysql forum, and include *exactly* what commands you are typing, the
*exact* output, what you expected to happen, etc.  Your message does not
include nearly enough information.

Brian


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Lakkimsetti, Chalapathi G]

Hi,


   I want to work on mysql in linux. i have gentoo linux in my system. After i 
loaded mysql5.0.17, if i want to install the mysql it is giving error "NO 
file/directory found" eventhough it is having that file.


can anyone help me reagarding that

truly,
chalapathi g lakkimsetti. 





Sent via the WebMail system at MAIL1.GANNON.EDU


 
   


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: (no subject)

[Bob Proulx]

刘玉 wrote:
>  link -nologo -DLL -SUBSYSTEM:WINDOWS -PDB:NONE -DEBUG -DEBUGTYPE:CV 
> -OUT:"libnsp
> [...]
> link: invalid option -- n

It is obviously complaining about the -n option.  But we don't know
too much about DOS systems here.  I suggest you discuss this on the
Cygwin list.  They can help you better than we can.

  http://cygwin.com/lists.html

Also, for some reason this message seems to have been lost in the
gnu.org mailq for quite some time.  It was just processed.

> Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
> by proulx.com (Postfix) with ESMTP id B187C4B796
> for <[EMAIL PROTECTED]>; Tue, 12 Jul 2005 18:23:29 -0600 (MDT)
> [...]
> Received: from [199.232.76.173] (helo=monty-python.gnu.org)
> by lists.gnu.org with esmtp (Exim 4.43) id 1DkYak-0005Gb-LO
> for bug-coreutils@gnu.org; Mon, 20 Jun 2005 22:34:22 -0400
> Date: Tue, 21 Jun 2005 10:03:03 +0800

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[刘玉]

你好：我在编译nss时出现如下错误不知何故,请指教.
 link -nologo -DLL -SUBSYSTEM:WINDOWS -PDB:NONE -DEBUG -DEBUGTYPE:CV 
-OUT:"libnsp
r4.dll" -MAP /BASE:0x3000  advapi32.lib wsock32.lib ./prvrsion.obj io/./prfd
cach.obj io/./prmwait.obj io/./prmapopt.obj io/./priometh.obj io/./pripv6.obj io
/./prlayer.obj io/./prlog.obj io/./prmmap.obj io/./prpolevt.obj io/./prprf.obj i
o/./prscanf.obj io/./prstdio.obj threads/./prcmon.obj threads/./prrwlock.obj thr
eads/./prtpd.obj linking/./prlink.obj malloc/./prmem.obj md/./prosdep.obj memory
/./prshm.obj memory/./prshma.obj memory/./prseg.obj misc/./pralarm.obj misc/./pr
atom.obj misc/./prcountr.obj misc/./prdtoa.obj misc/./prenv.obj misc/./prerr.obj
 misc/./prerror.obj misc/./prerrortable.obj misc/./prinit.obj misc/./prinrval.ob
j misc/./pripc.obj misc/./prlog2.obj misc/./prlong.obj misc/./prnetdb.obj misc/.
/prolock.obj misc/./prrng.obj misc/./prsystem.obj misc/./prthinfo.obj misc/./prt
pool.obj misc/./prtrace.obj misc/./prtime.obj malloc/./prmalloc.obj io/./prdir.o
bj io/./prfile.obj io/./prio.obj io/./prsocket.obj misc/./pripcsem.obj threads/.
/prcthr.obj threads/./prdump.obj threads/./prmon.obj threads/./prsem.obj threads
/combined/./prucpu.obj threads/combined/./prucv.obj threads/combined/./prulock.o
bj threads/combined/./prustack.obj threads/combined/./pruthr.obj md/windows/./nt
misc.obj md/windows/./ntsec.obj md/windows/./ntsem.obj md/windows/./ntinrval.obj
 md/windows/./ntgc.obj md/windows/./ntio.obj md/windows/./ntthread.obj md/window
s/./ntdllmn.obj md/windows/./win32_errors.obj md/windows/./w32ipcsem.obj md/wind
ows/./w32poll.obj md/windows/./w32rng.obj md/windows/./w32shm.obj  ./nspr.res
link: invalid option -- n
Try `link --help' for more information.
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[3]: *** [libns
pr4.dll] Error 1
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[3]: Leaving di
rectory `d:/mozilla-source-1.7.5/mozilla/nsprpub/WINNT5.0_DBG.OBJ/pr/src'
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[2]: *** [expor
t] Error 2
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[2]: Leaving di
rectory `d:/mozilla-source-1.7.5/mozilla/nsprpub/WINNT5.0_DBG.OBJ/pr'
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[1]: *** [expor
t] Error 2
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe[1]: Leaving di
rectory `d:/mozilla-source-1.7.5/mozilla/nsprpub/WINNT5.0_DBG.OBJ'
d:\nss\nss\software\wintools\buildtools\windows\bin\x86\gmake.exe: *** [build_ns
pr] Error 2
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: sys/mount.h: present but cannot be compiled (was: no subject)

[Steven P Schubiger]

On  8 Apr, Stephen Mc Gowan wrote:

: configure: WARNING: sys/mount.h: see the Autoconf documentation
: configure: WARNING: sys/mount.h: section "Present But Cannot Be Compiled"

Did you have a glance at the documentation?

Steven



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Stephen Mc Gowan]

While "make install" in "/usr/ports/sysutils/coreutils" I encountered
this error. I'm running FreeBSD 5.4 preRelease

configure: WARNING: sys/mount.h: present but cannot be compiled
configure: WARNING: sys/mount.h: check for missing prerequisite headers?
configure: WARNING: sys/mount.h: see the Autoconf documentation
configure: WARNING: sys/mount.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/mount.h: proceeding with the preprocessor's result
configure: WARNING: sys/mount.h: in the future, the compiler will take
precedence
configure: WARNING: ##  ##
configure: WARNING: ## Report this to bug-coreutils@gnu.org ##
configure: WARNING: ##  ##
-- 

Stephen Mc Gowan


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[[EMAIL PROTECTED]]

Hello,
 I use debian sarge for alpha processor.
My installation contains coreutils 5.2.1 and I note
that du utility doesn't count correctly disk usage
for directory over 4GB.

For example I have a directory sarge-20041016
that contains a DVD iso image. The output of
"ll" is the following and it reports fine filesize.

alpha:/mnt/sdd2# ll sarge-20041016
total 4544832
-rw-r--r--  1 tullio tullio 4653907968 Oct 16 05:10 sarge-alpha-1.iso

If I type du, I see the following output
alpha:/mnt/sdd2# du -s *
350528  sarge-20041016 <--- du displays only ~ 350MB
alpha:/mnt/sdd2#

So I searched in coreutils source file where du calculates used space
and I have tried this simple solution:
--- coreutils-5.2.1/src/du.c.orig   2005-03-22 23:22:58.740931368 +0100
+++ coreutils-5.2.1/src/du.c2005-03-23 12:56:36.854330472 +0100
@@ -382,7 +382,7 @@
 {
   size = (apparent_size
  ? sb->st_size
- : ST_NBLOCKS (*sb) * ST_NBLOCKSIZE);
+ : (uintmax_t)ST_NBLOCKS (*sb) * ST_NBLOCKSIZE);
 }

   if (first_call)



I think the real problem is * operation that exceed some 32 bit wide type.
On my alpha system sizeof returns:
   sizeof(int)=4 byte
   sizeof(long)=8 byte
   sizeof(long long)=8 byte
   sizeof(uintmax_t)=8 byte

Thanks,
   tullio





6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Jan Engelhardt]

Hello list,


since there have been no replies to the discussion about sort-dirs-first 
option, I repost this feature request and would like to see this feature being 
included in the mainstream coreutils.

http://lists.gnu.org/archive/html/bug-coreutils/2004-08/msg00113.html


Jan Engelhardt
-- 


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

(no subject)

[Bruce Korb]

>From - Tue Dec 16 11:48:45 2003
X-Mozilla-Status: 8001
X-Mozilla-Status2: 
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 16 Dec 2003 11:47:21 -0800
From: Bruce Korb <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: getpwnam(1) ?
Content-Type: multipart/mixed;
 boundary="136311A7BB107C214BB1D637"

This is a multi-part message in MIME format.
--136311A7BB107C214BB1D637
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I was writing another shell script and needed a full user name
(i.e., the "comment" entry from /etc/passwd).  Grepping and sedding
is such a nuisance, especially since there is a POSIX lib call to
do the job:  getwpnam(3).  Why not just expose this (and other?)
lib/sys calls with a wrapper program?  Attached is something I threw
together that has the following usage:

$ getpwnam -?
getpwnam - Get password entries - Ver. 1.2
USAGE:  getpwnam [ - | -- ]... [ user-name-or-id ]

   -n, --name Print the user name
   -p, --passwd   Print the (encrypted) password
   -u, --uid  Print the user id
   -g, --gnamePrint the group name
   -G, --gid  Print the group id
   -N, --gecosPrint the real user name (comment string)
   -d, --dir  Print the home directory
   -s, --shellPrint the login shell
   -A, --all  Print everything
- prohibits these options:
name
passwd
uid
gname
gid
gecos
dir
shell
   -V, --verbose  Verbose output
   -v, --version[=arg]Output version information and exit
   -?, --help Display usage information and exit
   -!, --more-helpExtended usage information passed thru pager

Options are specified by doubled hyphens and their name
or by a single hyphen and the flag character.

This command uses getpwnam(3) or getpwuid(3) to obtain the requested
information from the passwd database.  If a user name or user id is
not provided, the information for the current user is obtained.
The results are printed in the order selected.  If you select no options,
nothing is printed on success, but the user name/user id will have been
validated.

please send bug reports to:  [EMAIL PROTECTED]
$ getpwnam -A
bkorb x 4438 fcf 119 Bruce Korb /u/bkorb /bin/ksh
$ getpwnam -A -V
user name:bkorb
password: 'x' (encrypted)
user id:  4438
group name:   fcf
group id: 119
full name:Bruce Korb
directory:/u/bkorb
login shell:  /bin/ksh
--136311A7BB107C214BB1D637
Content-Type: text/plain; charset=us-ascii;
 name="getpwnam.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="getpwnam.c"


#include 

#include 

#include 
#include 
#include 
#include 
#ifdef __sun
# include 
#else
# include 
#endif

#include "opts.h"

void
printInfo( struct passwd* pw );

void
printInfoVerbosely( struct passwd* pw );

int
main( int argc, char** argv )
{
static const char zBadUser[] =
"%s error:  '%s' is not a valid user name or id\n";

uid_t uid = getuid();
struct passwd*  pw;
char*  pzUser;

{
int ct = optionProcess( &getpwnamOptions, argc, argv );
argc  -= ct;
pzUser = argv[ ct ];
}

switch (argc) {
default:
fputs( "Error:  Too many command line arguments\n", stderr );
USAGE( EXIT_FAILURE );
/* NOTREACHED */

case 1:
pw = getpwnam( pzUser );
if (pw != NULL)
break;
errno = 0;
{
char* pz;
long  l = strtol( pzUser, &pz, 0 );
switch (l) {
case LONG_MIN:
case LONG_MAX:
case 0:
if (errno != 0) {
fprintf( stderr, zBadUser, getpwnamOptions.pzProgName,
 pzUser );
USAGE( EXIT_FAILURE );
}
}
uid = (uid_t)l;
}
/* FALLTHROUGH */

case 0:
pw = getpwuid( uid );

if (pw != NULL)
break;

if (argc == 0) {
fprintf( stderr, "%s error:  uid %d has no password entry\n",
 getpwnamOptions.pzProgName, uid );
} else {
fprintf( stderr, zBadUser, getpwnamOptions.pzProgName, pzUser );
}
return EXIT_FAILURE;
}

if (selectCt > 0) {
if (HAVE_OPT( VERBOSE ))
printInfoVerbosely( pw );
else
printInfo( pw );
}

return EXIT_SUCCESS;
}

void
p

Re: (no subject)

[Bob Proulx]

Gary Leach wrote:
> I am trying to install a client agent for CA.

I have no idea what that is.

> This is on a RedHat v9 box.  It states to type "install" to install,
> but I keep getting an error.  "install: too few arguments" I am very
> green with Linux, sure could use some help.

I am sure you were directed here because the 'install --help' message
asks you to report bugs here.  But that only means you are running the
/usr/bin/install program on your computer which is part of the GNU
coreutils which is part of the GNU operating system.  I really don't
think this is the install program from your "client agent for CA",
whatever that is.  I am sure that /usr/bin/install is working fine.
It is a copy-like program used by software installation scripts to
install software in a system.  But it is not typically used by someone
on keyboard as you are doing to install another package.  That package
would be the candidate to use the /usr/bin/install program.

I am sorry but I don't think any of us over here can help you.  You
will need to dig into the problem more yourself.

If the instructions are saying "install" to install that seems really
strange since they should almost certainly know that you would get the
command from /usr/bin/install.  Try listing the directory and seeing
if there is an executable "install" program/script in the directory of
your "client agent for CA" and if so then run that explicitly with the
full path.

  ./install
or
  /cdrom/install

Hope that helps.  Good luck!

Bob


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

(no subject)

[Gary Leach]

Hi,
I am trying to install a client agent for CA.  This is on a RedHat v9 box.
It states to type "install" to install, but I keep getting an error. 
"install: too few arguments"
I am very green with Linux, sure could use some help.
Thanks,
Gary



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

Re: (no subject)

[Paul Jarc]

"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


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

(no subject)

[Daniel de la Cruz]

mandrake 9.1
remove file feature
rm --.xxx

cant delete names that start with 2 dashes '-'



http://www.jcmcomputers.com";>www.jcmcomputers.com 

_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail



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

[no subject]

[Mark Wilson]

I got a FAIL for file-type after doing ./configure; make

My system is Mac OS X 10.2.6

Making check in ls
make  check-TESTS
PASS: inode
PASS: dangle
out2 exp2 differ: char 21, line 3
3c3
< fifo
---
> fifo|
5,7c5,7
< slink-dangle
< slink-dir
< slink-reg
---
> slink-dangle@
> slink-dir@
> slink-reg@
FAIL: file-type
PASS: recursive
PASS: dired
PASS: infloop
PASS: rt-1
PASS: time-1
PASS: symlink-slash
PASS: follow-slink
PASS: no-arg
==
1 of 11 tests failed
Please report to [EMAIL PROTECTED]
==
make[3]: *** [check-TESTS] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1
Regards,

Mark Wilson



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

[no subject]

[Tim Care]

Got this error message while running make check for the coreutils-5.0 I
downloaded from the web.

Making check in sort
make  check-TESTS
PASS: sort-tests
==
All 1 tests passed
==
Making check in stty
make  check-TESTS
FAIL: row-col-1
PASS: basic-1
==
1 of 2 tests failed
Please report to [EMAIL PROTECTED]
==
*** Error code 1
make: Fatal error: Command failed for target `check-TESTS'
Current working directory
/home/itstpc/apachedir/apache/coreutils-5.0/tests/stty
*** Error code 1
make: Fatal error: Command failed for target `check-am'
Current working directory
/home/itstpc/apachedir/apache/coreutils-5.0/tests/stty
*** Error code 1
make: Fatal error: Command failed for target `check-recursive'
Current working directory /home/itstpc/apachedir/apache/coreutils-5.0/tests
*** Error code 1
make: Fatal error: Command failed for target `check-recursive'


>   Tim
> 
>   Tim Care
>   Gulf International Bank (UK) Limited
>   One Knightsbridge, London SW1X 7XS
> 
>   Voice: 020 7259 3426 Mobile: 07870 670780
>   e-mail: [EMAIL PROTECTED]
>   Switchboard: 020 7259 3456  Fax: 020 7259 6060
> 
> 
> 

"Gulf International Bank (UK) Limited of One Knightsbridge, London SW1X 7XS is 
regulated by the Financial Services Authority.

This e-mail message and any file transmitted with it is confidential to the intended 
recipient and may contain confidential, proprietary or legally privileged information. 
If you are not the intended recipient, you may not copy, distribute or disclose the 
contents to anyone, nor take any action in reliance on its contents. Should you 
receive this message in error, please immediately delete it and all copies of it from 
your system, destroying any hard copies and notify the sender."
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils