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/servi
found that tail(1)
crashes, reporting:
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected
unless all three of stdin, stdout and stderr are open. Whilst it
probably does
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:
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)
>> cras
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
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/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected
unless all three
> Date: Mon, 17 Jan 2005 21:19:05 +0100 (CET)
> From: Oliver Fromme <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> Xin LI <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 13, 2005 at 01:01:44PM -0600, Doug Poland wrote:
> > > Cool, I currently get this functionality from misc/xtail. xtail was on
Xin LI <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 13, 2005 at 01:01:44PM -0600, Doug Poland wrote:
> > Cool, I currently get this functionality from misc/xtail. xtail was on
> > my short list of "must-have" ports.
>
> Would you please share the list with us? I think it would be helpful
> if
On Thu, Jan 13, 2005 at 01:01:44PM -0600, Doug Poland wrote:
> Cool, I currently get this functionality from misc/xtail. xtail was on
> my short list of "must-have" ports.
Would you please share the list with us? I think it would be helpful
if we know the needs :-)
Cheers,
--
Xin LI http://w
On Thu, Jan 13, 2005 at 07:56:52PM +0100, Ronald Klop wrote:
> Hello,
>
> The command 'tail' has a very nice feature in HEAD.
> It can do 'tail -f' on multiple files. Is it possible that this gets
> backported to RELENG_5?
>
> I saw in cvsweb, that the
On Thu, Jan 13, 2005 at 07:56:52PM +0100, Ronald Klop wrote:
> Hello,
>
> The command 'tail' has a very nice feature in HEAD.
> It can do 'tail -f' on multiple files. Is it possible that this gets
> backported to RELENG_5?
>
Cool, I currently get this fun
Hello,
The command 'tail' has a very nice feature in HEAD.
It can do 'tail -f' on multiple files. Is it possible that this gets
backported to RELENG_5?
I saw in cvsweb, that the committer was paul, but I don't know his e-mail
address to ask him.
Or should I file
From: Mamoru Iwaki <[EMAIL PROTECTED]>
Subject: newpcm does not play back the tail of sound
Date: Sun, 21 Oct 2001 18:47:37 +0900 (JST)
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=31398
You can easily have an experience as follows.
% cat swedish.au > /dev/audio
This sou
Hello,
I reported a bug of sound system in 4-STABLE, i.e. kern/31398:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=31398
>
> >Category: kern
> >Responsible:freebsd-bugs
> >Synopsis: newpcm does not play back the tail of sound
> >Arrival-Date: Su
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
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
some sort of add-on that you
:: could use to MAKE the system more user-friendly, etc would be a very
:: worthwhile (although rather large) project, and 'A Good Thing'. Changing
:: the default behavior of the entire system to be more like Windows is NOT.
So you're basically sayin
directory, it will warn you that it
> isn't a "regular file".
Only because vi specifically recognises that case.
> :: I see no reason to correct tail's
> :: behavior. If you sit there and do `tail' on a directory all day long,
> :: then you've got probl
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
nd if you yourself don't want to look at it then you shouldn't
> > ask the system to show it to you. "Doctor, it hurts when I poke
> > myself in the eye.." :)
>
> We have rm -rf to protect us from doing things to directories (IE: rm
> /poop).
This avoids ca
Juha> So the best thing to do is to keep the current behaviour for
Juha> tail et al, but make it accessible through a flag.
No, the best thing to do is to run Windows. Microsoft Excels (nyuk nyuk)
in telling you all the things you shouldn't do.
--lyndon
To Unsubscribe: send mail to [EMAIL
> "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 typ
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
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
rove that there is no use for the output of
> :: tail on a directory, adding code to tail to generate an error in that
> :: case is silly.
>
> If you are a typist with 100% accuracy, there is of course no need for any
> error handling in any program.
>
> Is there any us
:: 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
:: 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
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 t
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
t, do they? You go tail /var/log/htpd
> and your fat fingers hit enter instead "accesslog". If there was a point
to
> that behaviour, I wouldn't argue about it, but since there doesn't seem to
> be any, I might just flame away for a little longer. ;-)
To Unsubscribe: s
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, yo
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, y
t; >
> > On Sunday 29 April 2001 23:29, Juha Saarinen wrote:
> > > Same here, on 4.2-STABLE:
> > >
> > > bash-2.04$ tail /
> > >
> > > .
> > > ..
> > >dev=data1[homez
> >
nt. I was thinking, why
> couldn't tail do that? Since it can watch files for changes and display
> those, why not for a command?
>
> I tried tail -f |df -h and could not get it to update. I would appreciate
> your thoughts.
>
> I am also cc'ing this to stable in caus
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 thinking, why
couldn't tail do that? Since it can watch files for ch
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: forwar
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, th
39 matches
Mail list logo
