If you do: lastcomm -f does-not-exist you get couldn't open file 'does-not-exist': No such file or directory and it exits with a status of 141. If you do: zcat /var/account/pacct.1.gz | lastcomm -f - you get no output and lastcomm also exits with status 141. It should (ideally) read from stdin if given an argument of "-f -", or failing that at least give an error messages that the file "-" doesn't exist. Mark.
tags 159090 + upstream tags 159090 + wontfix thanks Mark, Mark Sheppard writes: Mark> Package: acct Mark> Version: 6.3.5-32 Mark> Severity: normal Mark> Mark> If you do: Mark> Mark> lastcomm -f does-not-exist Mark> Mark> you get Mark> Mark> couldn't open file 'does-not-exist': No such file or directory Mark> Mark> and it exits with a status of 141. If you do: Mark> Mark> zcat /var/account/pacct.1.gz | lastcomm -f - Mark> Mark> you get no output and lastcomm also exits with status 141. It should Mark> (ideally) read from stdin if given an argument of "-f -", or failing Mark> that at least give an error messages that the file "-" doesn't exist. Acknowledged. Chances of this actually getting fixed are not good. I have not heard from the upstream author in years, for all intents and purposes he can be considered "lost". I have too many other things to look after to fix this myself. Would you be interested in trying to patch this? Dirk
Noel, FYI, and if the email address still works... Let me know if you're still around. Cheers, Dirk----- Forwarded message from Mark Sheppard <mark@ddf.net> ----- Envelope-to: edd@edd.debian.net Delivery-date: Sun, 01 Sep 2002 06:18:13 -0500 Reply-To: Mark Sheppard <mark@ddf.net>, 159090@bugs.debian.org From: Mark Sheppard <mark@ddf.net> To: submit@bugs.debian.org Subject: Bug#159090: acct: "lastcomm -f -" broken Package: acct Version: 6.3.5-32 Severity: normal If you do: lastcomm -f does-not-exist you get couldn't open file 'does-not-exist': No such file or directory and it exits with a status of 141. If you do: zcat /var/account/pacct.1.gz | lastcomm -f - you get no output and lastcomm also exits with status 141. It should (ideally) read from stdin if given an argument of "-f -", or failing that at least give an error messages that the file "-" doesn't exist. Mark.----- End forwarded message -----
I finally got round to having a look at this. To fix the bug in my report was quite simple (see patch below), but unfortunately due to the shared code it had knock on effects for some of the other utilities in the acct package. For example doing a "last -f -" showed all the entries as warping because it's reading the entries in the opposite order to normal. To fix this would mean altering al_local.cpp to change a lot of #defines to be if()s. I haven't got the time or the inclination to do that, so I'm giving up. Mark.--- acct-6.3.5/file_rd.c Tue Oct 14 01:28:36 1997 +++ acct-6.3.5-mark1/file_rd.c Sun Dec 22 19:15:16 2002 @@ -87,15 +87,23 @@ if (fri->the_files == NULL) return 0; /* no more files == no more records */ - fri->fp = file_open (fri->the_files->name, 0); - if (fri->fp == NULL) + if (strcmp(fri->the_files->name, "-") == 0) { - /* make sure to free this list entry */ - goto no_more_records_no_close; + /* read from stdin, have to do it forwards! */ + fri->fp = stdin; + } + else + { + fri->fp = file_open (fri->the_files->name, 0); + if (fri->fp == NULL) + { + /* make sure to free this list entry */ + goto no_more_records_no_close; + } + + if (fri->backwards) + fseek (fri->fp, 0, SEEK_END); /* go to end of file */ } - - if (fri->backwards) - fseek (fri->fp, 0, SEEK_END); /* go to end of file */ fri->rec_number = 0; /* start over! */ fri->name = fri->the_files->name; @@ -104,7 +112,7 @@ /* We have to do things differently depending on our direction of reading */ - if (fri->backwards) + if (fri->fp != stdin && fri->backwards) { long offset, max_recs, recs_to_read; @@ -184,7 +192,7 @@ { char *rec; - if (fri->backwards) + if (fri->fp != stdin && fri->backwards) rec = (char *) fri->buffer + (--fri->recs_left * fri->record_size); else rec = (char *) fri->buffer + ((fri->recs_read - fri->recs_left--) --- acct-6.3.5/lastcomm.1 Mon Mar 23 06:26:12 1998 +++ acct-6.3.5-mark1/lastcomm.1 Sun Dec 22 19:24:00 2002 @@ -130,7 +130,10 @@ Read from the file .I filename instead of -.I acct +.I acct. +If you use a filename of `-' then the standard input will be read. +Note that if you do this the records will appear oldest first rather +than newest first as when reading from a file. .TP .BI \-\-ahz " hz" Use this flag to tell the program what
The problem show specifically when using the ksh package, as opposed to the pdksh package (or possibly others). Running: % cat pacct | (ls -l /proc/self/fd) total 0 lrwx------ 1 root root 64 Mar 19 13:33 0 -> socket:[9391328] lrwx------ 1 root root 64 Mar 19 13:33 1 -> /dev/pts/0 lrwx------ 1 root root 64 Mar 19 13:33 2 -> /dev/pts/0 lr-x------ 1 root root 64 Mar 19 13:33 3 -> /proc/30907/fd And then: % cat pacct | lastcomm -f - couldn't open file '/proc/self/fd/0': No such device or address If the shell is switched to pdksh, tcsh, or sh (which I suppose is dash), then the pipe works okay, e.g.: % sh %% cat pacct | (ls -l /proc/self/fd) total 0 lr-x------ 1 root root 64 Mar 19 13:39 0 -> pipe:[9393029] lrwx------ 1 root root 64 Mar 19 13:39 1 -> /dev/pts/0 lrwx------ 1 root root 64 Mar 19 13:39 2 -> /dev/pts/0 lr-x------ 1 root root 64 Mar 19 13:39 3 -> /proc/30946/fd %% cat pacct | lastcomm -f - | head accton S root __ 0.00 secs Sat Mar 19 00:26 acct root __ 0.00 secs Sat Mar 19 00:26 acct root __ 0.00 secs Sat Mar 19 00:26 invoke-rc.d root __ 0.00 secs Sat Mar 19 00:26 acct root __ 0.00 secs Sat Mar 19 00:26 apache2 root __ 0.00 secs Sat Mar 19 00:26 cmp root __ 0.00 secs Sat Mar 19 00:26 which root __ 0.00 secs Sat Mar 19 00:26 apt-config root __ 0.00 secs Sat Mar 19 00:26 apt-config root __ 0.00 secs Sat Mar 19 00:26 This behavior is consistent across all platforms that I have at my disposal, i386, powerpc, and armel.
reassign 159090 ksh thanks On Sat, Mar 19, 2011 at 2:04 PM, Jeff Green <jeff@kikisoso.org> wrote: [...] [...] ksh's handling of pipes, not lastcomm and all not supporting sockets -- especially when it works with many of the most common shells. Please let me know if you disagree or can explain the reasoning further to say the issue is in acct -- for now, reassigning to ksh, since ls also sees the pipe building fd/0 as a socket. Regards, Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> Freenode: cyphermox, Jabber: mathieu.tl@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93
reassign 159090 acct thanks This bug was misassigned to ksh; it concerns acct's lastcomm and I'm reassigning it back. The reported issue is no longer reproducible on the current version (acct 6.6.4-11, ksh93u+m 1.0.10-4): "zcat /tmp/pacct.1.gz | lastcomm -f -" now reads the records from stdin correctly and exits 0. This looks resolved and can probably be closed. Minor separate observation: "lastcomm -f does-not-exist" now prints a clean "couldn't open file 'does-not-exist': No such file or directory" error but exits 0 rather than non-zero. That's a distinct issue from this report and worth tracking separately if it matters.