On 2021-May-06 19:07:23 -0400, monochrome wrote:
...
>On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
...
>> server% tail /COPYRIGHT <&-
>> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
>> /usr/src/lib/libcasper/libcasper/service.c, line 394.
>> tail: unable t
On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote:
Could you provide details how to reproduce this?
On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
wrote:
Since updating from 12-stable to 13-stable, I've found tha
On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
tail /COPYRIGHT <&-
I get a different error on a 13.0-RELEASE machine I converted from 12 to
current about a year ago:
$ tail /COPYRIGHT <&-
tail: can't limit stdio rights: Bad file descriptor
_
On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote:
>Could you provide details how to reproduce this?
>
>On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
> wrote:
>>
>> Since updating from 12-stable to 13-stable, I've found that tail(1)
>> crashes, reporting:
>> Assertion failed: (p
Could you provide details how to reproduce this?
On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
wrote:
>
> Since updating from 12-stable to 13-stable, I've found that tail(1)
> crashes, reporting:
> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
> /usr/src
Dan Langille <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Apr 2001, Chris Byrnes wrote:
> > We have rm -rf to protect us from doing things to directories (IE: rm
> > /poop).
>
> This avoids catastraphic file removals.
>
> > We need tail -argument to protect us from doing things to directories.
On Tue, May 01, 2001 at 07:30:18AM +0200, Steve O'Hara-Smith wrote:
> JS> Not sure about this; if you e.g. vi a directory, it will warn you that it
>
> It is dangerous to vi a directory, but it is not dangerous to tail
> one.
More to the point, opening a directory for writing is an error.
:: No, the behavior should stay the same by default, with a flag that can be
:: used to turn on "sanity checking". You would have to change FAR, FAR too
:: many things to make the whole system dafault to "typo proof" behavior.
::
:: Like I said in my previous message, having some sort of add-on t
On Tue, 1 May 2001, Juha Saarinen wrote:
> Note the "rare situations" -- it's not useful when you make a typo, or a
> mistake.
>
> :: Remember, a directory is treated as a
> :: regular file on unix filesystems.
>
> Not sure about this; if you e.g. vi a directory, it will warn you that it
> isn
Arthur W. Neilson III writes:
This very functionality, being able to cat a directory, saved my butt
some years ago on an unfamiliar sys5r2 box which had crashed and no
filesystem but root would mount. ls wasn't in the path and I
remembered I could use cat
On Mon, 30 Apr 2001, Chris Byrnes wrote:
> > It might be, depending on what you were feeding it to. I think the
> > point people are making is that directory data is, in certain cases,
> > also potentially useful for something they might conceivably want to
> > do, and if you yourself don't want
> "Juha" == Juha Saarinen <[EMAIL PROTECTED]> writes:
Juha> Note the "rare situations" -- it's not useful when you make
Juha> a typo, or a mistake.
A better fix would be to change your shell to /usr/local/bin/ispell.
Juha> So the best thing to do is to keep the current behaviour
> "Donn" == Donn Miller <[EMAIL PROTECTED]> writes:
Donn> Yeah, and you can do cat dirname | strings;
Another recipient of the Gratuitous Use of Cat award. 'strings dirname'
works just fine. (And if he didn't have ls available, it's a safe bet
that strings wasn't there, either ;-)
--lyn
I was going to let this one go, but...
:: Like so many people before you already explained, doing tail on a
:: directory IS useful in some rare situations, like for example, using
:: tar, and certain other things.
Note the "rare situations" -- it's not useful when you make a typo, or a
mistake.
On Tue, May 01, 2001 at 03:23:15AM -0600, Doug Russell wrote:
>
> You could then put your machine in "user friendly" mode if desired, but
> those of us who expect Unix to behave like Unix can set it to mode
> 0. There could be levels in between without the "Are you sure you are
> really sure you
:: UNIX is about doing what you ask for. You want to tail/cat a
:: directory, who is the system to tell you otherwise.
That's just silly.
Who hasn't mistakenly tailed/cat'ed a directory?
I thought the "User-unfriendliness Is Cool" era was long buried.
-- Juha
To Unsubscribe: send mail to [E
From: Mike Meyer <[EMAIL PROTECTED]>
Subject: RE: tail
Date: Mon, 30 Apr 2001 00:15:53 -0500
> On Unix, it's generally more important to make sure the user can shoot
> anything they want than it is to keep the user from shooting
> themselves in the foot.
How does that quo
Juha Saarinen <[EMAIL PROTECTED]> types:
> :: The real issue is why should a command raise an error for no good
> :: reason. Either a kernel panic or a message is a bit extreme just
> :: because a user issued a command that someone else thinks is
> :: unusual. Until you can prove that there is no
:: Not so. Being able to read a directory with normal tools is (on rare
:: occasions) useful - diagnosing a mess if nothing else. Being
:: unable to do so
:: brings no useful functionality it just looks prettier.
So seeing a mess with tail/cat is useful to you?
To Unsubscribe: send mail to
:: The real issue is why should a command raise an error for no good
:: reason. Either a kernel panic or a message is a bit extreme just
:: because a user issued a command that someone else thinks is
:: unusual. Until you can prove that there is no use for the output of
:: tail on a directory, ad
Juha Saarinen <[EMAIL PROTECTED]> types:
> :: Well, yes, tail on a directory is a silly thing to do unthinkingly.
> :: But the silly one isn't tail, it's the user who issued the command
> :: without thinking.
> So the butter-fingered luser must be punished?
Having to live with the consequences of
On Mon, 30 Apr 2001 17:08:47 +1200
"Juha Saarinen" <[EMAIL PROTECTED]> wrote:
JS> More desirable behaviour, IMO.
Not so. Being able to read a directory with normal tools is (on rare
occasions) useful - diagnosing a mess if nothing else. Being unable to do so
brings no useful functionality
I'm sure my mail filters can handle it, but this has been the typical
practice for most programs. vi cat and a few others, ee will actually give
an error, but its one of the few. You'd have to speak to some of the
developers as to why it does this.
> Well, most people don't, do they? You go tail
On Mon, Apr 30, 2001 at 05:08:47PM +1200, Juha Saarinen wrote:
> Well, it's silly to do that unthinkingly. Here's what happens on a Debian
> box:
>
> juha@cyrus:~$ tail /
> tail: /: Is a directory
>
> More desirable behaviour, IMO.
FYI, and maybe surprisingly, you're about to start a flame war.
Juha Saarinen <[EMAIL PROTECTED]> types:
> :: tail is doing as ordered. Directories and files are the same. So it's
> :: giving you the last ten lines of the file /
>
> Tail voss only obeyink orters???
>
> Well, it's silly to do that unthinkingly.
Well, yes, tail on a directory is a silly th
but its not, its a file, almost no other tool errors out when you try to
modify a "directory"
On Monday 30 April 2001 00:07, Chris Byrnes wrote:
> Id expect an output of something like "Error: / is a directory" or
> something
>
>
> Chris Byrnes <[EMAIL PROTECTED]>
> JEAH Communications, LLC.
>
On Sun, Jan 28, 2001 at 01:25:51PM -0600, Justin W. Pauler wrote:
> I am not sure if this is a command, but if not, I think it would be useful. I
> have often needed to watch output from different commands like df, but I have
> to continously run the command to get the latest amount. I was think
Fred Gilham wrote:
> In 4.1-stable tail -f over NFS polls rather than blocking.
Yes, this is acknowledged in the kqueue() manual page. Try this patch,
it seems to work for me so I might commit it if no-one objects.
Index: forward.c
==
Ben Smithurst wrote:
> Fred Gilham wrote:
>
>> In 4.1-stable tail -f over NFS polls rather than blocking.
>
> Yes, this is acknowledged in the kqueue() manual page. Try this patch,
> it seems to work for me so I might commit it if no-one objects.
Scratch that, the problem is fixed in -current
29 matches
Mail list logo
