bug#65674: (no subject)
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)
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)
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:
bug#34968: (no subject)
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:
bug#18949: (no subject)
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)
close 19681 stop Pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00 closing.
bug#19375: (no subject)
tags 19375 fixed close 19375 stop pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=178f8e79dcd1e0b8bbb3b04da664d05eaae56186 closing.
bug#19154: (no subject)
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 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)
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)
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 http://gnu.org/licenses/gpl.html. 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
bug#6377: Subject: inaccurate character class processing
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux pony.netsoft.ro 2.6.32.12-115.fc12.x86_64 #1 SMP Fri Apr 30 19:46:25 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 0 Release Status: release Description: (I'm not sure if this a bash or a coreutils issue). ls [A-Z]* doesn't work as expected/documented. I'd want/expect it to list the filenames starting with an uppercase letter. Thank you for looking at it! Repeat-By: In an empty directory, create files like touch a A b B z Z Now, ls [A-Z]* outputs A b B z Z (why 'b' and 'z' - and/or where's 'a'...?!!) and ls [a-z]* outputs a A b B z (why 'A' and 'B' - and/or where's 'Z'...?!!)
bug#6377: Subject: inaccurate character class processing
tags 6377 + notabug On 08/06/10 14:48, Iosif Fettich wrote: (I'm not sure if this a bash or a coreutils issue). ls [A-Z]* doesn't work as expected/documented. The logic is in bash but it's not an issue. It's using the collating sequence of your locale $ touch a A b B z Z $ echo [A-Z]* A b B z Z $ export LANG=C $ echo [A-Z]* A B Z
bug#6377: Subject: inaccurate character class processing
On Tue, Jun 8, 2010 at 4:48 PM, Iosif Fettich ifett...@netsoft.ro wrote: ... ls [a-z]* outputs a A b B z (why 'A' and 'B' - and/or where's 'Z'...?!!) it's a classic problem with the locale, the range [a-z] contains the capital letters for some locale definitions ie a-z is aAbB z (Z is after the z) As a workaround you can export LC_COLLATE=C, or maybe use [[:lower:]] instead of [a-z]
bug#6377: Subject: inaccurate character class processing
On Tue, Jun 08, 2010 at 04:48:08PM +0300, Iosif Fettich wrote: ls [A-Z]* doesn't work as expected/documented. I'd want/expect it to list the filenames starting with an uppercase letter. The results of this are dependent upon your locale. If your locale is set to C or POSIX, you will get what you expect. If your locale is set to something else (such as en_US.utf8) then you will get something completely different. I explain why this happens, on http://mywiki.wooledge.org/locale. The glob in your command is expanded by bash (not ls), so in order to get the results you want, your locale variables would have to be set to C/POSIX *before* expanding the glob. In other words, LANG=C ls [A-Z]* will not work, since that sets the variable after expanding the glob. This would work, although it's extremely awkward (IMHO): LANG=C bash -c 'ls [A-Z]*' Another approach would be to permanently (or semi-permanently, e.g. just for one shell session) set the LC_COLLATE variable. Thus, export LC_COLLATE=C ls [A-Z]* This will cause the ordering of glob results (and also of results generated by ls itself, for example ls with no arguments, or ls dirname) to be in ASCII order, without throwing away the other locale features.
(no subject)
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
Re: (no subject)
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
firefox problem on Acer (was: (no subject))
-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)
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)
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
Re: (no subject)
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
(no subject)
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
Subject: [PATCH] date doc: warn at -d about LC_TIME
We also warn here about LC_TIME, so the user will know even if he
doesn't look in the @xref{Date input formats}.
Signed-off-by: jidanni jida...@jidanni.org
---
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..35d98b2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -13470,6 +13470,11 @@ format. It can contain month names, time zones,
@samp{am} and @samp{pm},
14:19:13.489392193 +0530} specifies the instant of time that is
489,392,193 nanoseconds after February 27, 2004 at 2:19:13 PM in a
time zone that is 5 hours and 30 minutes east of @acronym{ut...@*
+Note: input currently must be in locale independent format. E.g., the
+LC_TIME=C below is needed to print back the correct date in many locales:
+...@example
+date -d $(LC_TIME=C date)
+...@end example
@xref{Date input formats}.
@item -f @var{datefile}
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
@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 PE standard interface. You can find information about these adaptor from the PE web site. more on CPU32 hardware Coldfire The Coldfire has a 26pin header.
using gpg on Windows (was: (no subject))
-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\Documentsc:\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)
I think this is what the apache download page says to do to check the signature of the downloaded file c:\Users\MyName\Documentsc:\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\Documentsc:\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)
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)
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)
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
+++ b/tests/misc/md5sum
@@ -51,6 +51,14
(no subject)
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;
+ memcpy (newline
Re: (no subject)
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
RE: df reporting and removing files (Re: (no subject))
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
Re: df reporting and removing files (Re: (no subject))
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
(no subject)
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
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
(no subject)
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
sort bizard behavior [was: (no subject)]
-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
Re: (no subject)
(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
(no subject)
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: disk corruption [Was: (no subject)]
-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)
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: (no subject)
[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)
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
logical paths [was: (no subject)]
-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
logical paths (was: (no subject))
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
Re: logical paths (was: (no subject))
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 `..'. http://plan9.bell-labs.com/sys/doc/lexnames.html, http://plan9.bell-labs.com/sys/doc/lexnames.pdf, http://plan9.bell-labs.com/sys/doc/lexnames.ps 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
determining 64-bit hardware [was: (no subject)]
-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)
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)
Hi Bob! thank you for your help! Ralf ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
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
(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: (no subject)
刘玉 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)
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
Re: sys/mount.h: present but cannot be compiled (was: no subject)
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)
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)
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)
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
Re: (no subject)
Daniel de la Cruz [EMAIL PROTECTED] wrote: rm --.xxx cant delete names that start with 2 dashes '-' URL: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]
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
