fileargs_init(3) doesn't work without CAPABILITIES (was: Re: tail(1) broken in 13-stable)
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 to init casper: Socket is not connected >I get a different error on a 13.0-RELEASE machine I converted from 12 to >current about a year ago (bash and sh): > >$ tail /COPYRIGHT <&- >tail: can't limit stdio rights: Bad file descriptor I've done some more testing across a number of systems and narrowed the difference in behaviour down to the presence of the CAPABILITIES option in the kernel (it looks like I never added it to my kernel config on that system): If CAPABILITIES is present then the cap_rights_limit(2) call for the closed FD fails, generating the "can't limit stdio rights" error. (Whether this behaviour is reasonable is a different issue - it was introduced in r348708, based on https://reviews.freebsd.org/D20393 and the issue of closed file descriptors doesn't seem to have been considered). If CAPABILITIES is not present then the cap_rights_limit() failure is (correctly) ignored but the subsequent fileargs_init(3) call gets upset at opening a FD <= 2. This behaviour seems wrong - if CAPABILITIES aren't present in the kernel then the userland behaviour should be the same as if WITHOUT_CASPER is specified. IMO, this is a bug in fileargs_init(3). -- Peter Jeremy signature.asc Description: PGP signature
Re: tail(1) broken in 13-stable
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 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 doesn't make sense to call tail without stdout open. there's no obvious reason to require that stdin or stderr must be open. server% tail /COPYRIGHT <&- 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 (fixed quote with some additional tests) I get a different error on a 13.0-RELEASE machine I converted from 12 to current about a year ago (bash and sh): $ tail /COPYRIGHT <&- tail: can't limit stdio rights: Bad file descriptor works with sudo: $ sudo tail /COPYRIGHT <&- *California, Berkeley and its contributors." etc etc... but not as root, with a different error in sh: # tail /COPYRIGHT <&- Missing name for redirect. as root in bash: # tail /COPYRIGHT <&- tail: can't limit stdio rights: Bad file descriptor works as both user and root in ksh ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tail(1) broken in 13-stable
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 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tail(1) broken in 13-stable
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: (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 doesn't make sense to call tail without stdout open. there's >> no obvious reason to require that stdin or stderr must be open. server% tail /COPYRIGHT <&- 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 -- Peter Jeremy signature.asc Description: PGP signature
Re: tail(1) broken in 13-stable
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/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 doesn't make sense to call tail without stdout open. there's > no obvious reason to require that stdin or stderr must be open. > > -- > Peter Jeremy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: tail
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. > > This avoids nothing. I agree 100%. Furthermore, we would have to add such an -option to hundreds of tools, literally. That's not feasible. BTW, I often find myself needing to "edit" a directory (this is sometimes more handy than a bunch of "mv" commands). This doesn't work with vi, of course (you can read a directory, but you can't write it), so I wrote a small shell script that loads the directory (that is, the filenames) into your $EDITOR and writes them back afterwards (i.e. renames the files). http://www.secnetix.de/~olli/scripts/vils Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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. Since you normally use an editor to modify files, instead of just viewing them, it makes sense that vi warns you that you won't be able to write back your changes. It would not make sense for tail to warn you, because it only reads files. wopr:~$ perl -e 'open SPORK, ">tmp/" or die "$!"' Is a directory at -e line 1. wopr:~$ perl -e 'open SPORK, "tmp/" or die "$!"' wopr:~$ (See also "man 2 open".) -- Matthew Hunt <[EMAIL PROTECTED]> * Clearly there are more things in the http://www.pobox.com/~mph/ * heavens than anyone anticipated. -enp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
:: 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 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 saying that for normal users, tail et al should recognise special files like directories, but for superusers (and maybe in single user/maintenance mode) it should default to the old-style behaviour? That would indeed be a big project... I wouldn't worry about making FreeBSD "more like Windows". Have you ever tried the Windows (DOS/NT CMD) command line? -- Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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'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 problems. Surely, you might want to modifiy cat's > :: behavior, because some poor unsuspecting user might get some ugly > :: garbage printed to his terminal when he does 'cat' on a disk device. > > So the best thing to do is to keep the current behaviour for tail et al, but > make it accessible through a flag. Most of the time, that behaviour isn't > desirable, hence it should only be invoked if you really need it. 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 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. Later.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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 dirname as a crude ls in order to navigate. This helped me find fsck in an obscure directory and repair the hosed filesystems and recover the system. I've had a similar experience under like circumstances. I suspect that many system administrators, having painted themselves or found themselves painted into a corner, are glad that low-level functionality like this exists. -- Fred Gilham[EMAIL PROTECTED] And then [Clinton] turned to Hunter Thompson, of all people, and said with wholehearted fervor, "We're going to put one hundred thousand new police officers on the street." I was up all night persuading Hunter that this was not a personal threat. -- P. J. O'Rourke To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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 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 catastraphic file removals. > We need tail -argument to protect us from doing things to directories. This avoids nothing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
> "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 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 PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
> "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 ;-) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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. :: 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't a "regular file". :: 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 problems. Surely, you might want to modifiy cat's :: behavior, because some poor unsuspecting user might get some ugly :: garbage printed to his terminal when he does 'cat' on a disk device. So the best thing to do is to keep the current behaviour for tail et al, but make it accessible through a flag. Most of the time, that behaviour isn't desirable, hence it should only be invoked if you really need it. -- Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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 answered the last are you sure question correctly?", but > not quite totally bare. As you indicate, it is important to be free to make one's own choices. Here's one example of where the standard behaviour is used. At work we have various flavours of commercial unix, and a few diverse Linux boxes. No BSD to speak of. I need to teach very basic unix skills to the operators and give them some place to practise. For this I have chosen FreeBSD on a dedicated training crash box. FreeBSD serves as the generic BSD model, with nothing else mixed in, and the differences found on some of the other machines make good examples of SysV to compare. That gives them two basic unix styles to learn about, rather than several. For the most part FreeBSD tools behave like the tools on any other unix, and that is important, pitfalls and all. One of the most important things to learn in our environment is where the hidden dangers are. You can destroy a server with something as apparently innocent as cat, so our rule is always run file before cat. They must see that the behaviour happens the same way as on the majority of other systems, if they are to be able to tranfer the learning and see the validity in the general work rules. We also get a lot of value out of studying the outcomes of accidents during learning, e.g. what happens when you cat the wrong thing on one of those old terminals. People who are already novices on several other systems don't have any trouble doing basic stuff on FreeBSD, because it does what they expect, no big surprises. That is important in today's heterogeneous unix environments. If someone wanted a unix system to be easy to use as an internal desktop machine and didn't ever plan to use any other system, I might recommend RedHat because it employs a lot of startling (to us) changes to make things seem "easier", and has a certain confidence building feel at first. But I've never met such a person. -- Regards, -*Sue*- -- Regards, -*Sue*- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
:: 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 [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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 quote go, "Unix doesn't stop you from doing stupid things, because that would also stop you from doing clever things." - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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 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 use for the the garbage tail outputs on a directory? If there > is, I won't say anything else... Yes, there is. If you're monitoring a programm that creates a lot of files in a previously empty directory (for example, extracting a tar file into it), then: tail -f targetdir will do the trick, though it would be better to clean up the output (cat -v, maybe). Deciding for the users what actions are an error and which aren't is a *really* nasty habit. Windows does it all to often, which is one of the reasons Windows sucks. Linux - at least some distributions - seems to have picked up the habit from Windows. Oh well. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
:: 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 [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
:: 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, 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 use for the the garbage tail outputs on a directory? If there is, I won't say anything else... -- Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: tail
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 their own buttery fingers is punishment enough. Running tail on a file that's not ascii text - whether it's a directory, a binary, or something else - usually does strange things to the terminal, which will do. > :: More proof that linux isn't Unix. > :: > :: 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. > In that case, tail should cause a kernel panic if you try to run it on a > directory. If you really want to wallow in pendantry, please remember that > "shooting yourself in the foot" isn't the right metaphor in this context. Considering that it's the result of being butter-fingered, it seems highly appropriate. 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, adding code to tail to generate an error in that case is silly. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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 it just looks prettier. -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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 /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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 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. BSD tail and related tools have been treating directories as files for *many* years. The behavior goes back to the earliest UNIX systems. It will not change, nor is it worth arguing about. If you hate the behavior, put a 2-line shell script around tail, cat, and whatever other programs you want that aborts the operation if the argument's a directory. PGP signature
RE: tail
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 thing to do unthinkingly. But the silly one isn't tail, it's the user who issued the command without thinking. > Here's what happens on a Debian box: > > juha@cyrus:~$ tail / > tail: /: Is a directory > > More desirable behaviour, IMO. More proof that linux isn't Unix. 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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. > Toll-Free <1-866-AWW-JEAH> > > On Sun, 29 Apr 2001, David W.Chapman Jr. wrote: > > Has it ever been different, have you tried running cat / > > > > its just taking the last few lines of that. What are you expecting? > > > > On Sunday 29 April 2001 23:29, Juha Saarinen wrote: > > > Same here, on 4.2-STABLE: > > > > > > bash-2.04$ tail / > > > > > > . > > > .. > > >dev=data1[homez > > > usr > > > var.stand1 > > >etcnproc > > >bin > > mnt > > > zmodulesroot.sbinO > > > tmpD > > > > > > sy.cshr.profileECOPYRIGHTkernel.GENERICkernelH > > > compatG > > > kernel.oldAo > > > modules.oldOvinum0 > > > =vinum1data2Odata3~ > > > > > > n > > > slogfzshlibbash-2.04$ > > > > > > :: -Original Message- > > > :: From: [EMAIL PROTECTED] > > > :: [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Byrnes > > > :: Sent: Monday, 30 April 2001 16:25 > > > :: To: [EMAIL PROTECTED] > > > :: Subject: tail > > > :: > > > :: > > > :: awww# tail / > > > :: > > > :: . > > > :: .. > > > :: dev > > > ::usr > > > :: varstand > > > :: etc) > > > :: compat$procu% > > > ::binbootuC > > > :: > > > :: sys > > > :: mnt( > > > :: modulesrootusbinuC > > > :: > > > :: sys.cshrc.profile; COPYRIGHTkernelENERIC > > > :: ,tmp > > > :: > > > :: modules.ollibexec home7 > > > :: kernel.old5x > > > :: sshd.corst2iI1UR28-2000.tgzbackups9-23-2000.tar.gsh.coreS > > > :: > > > :: syslogd.coreawww# > > > :: > > > :: > > > :: wtf? > > > :: > > > :: > > > :: > > > :: > > > :: Chris Byrnes <[EMAIL PROTECTED]> > > > :: JEAH Communications, LLC. > > > :: Toll-Free <1-866-AWW-JEAH> > > > :: > > > :: > > > :: To Unsubscribe: send mail to [EMAIL PROTECTED] > > > :: with "unsubscribe freebsd-stable" in the body of the message > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail
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 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 cause it is a bug/feature... Mmm.. methinks you are confused ! The command as you tyoed it will have tail read it;s standard input, the terminal, and pipe it's output into df. Since df is not a filter it will ignore it. If it would work then you would need to change it around to "df | tail -f". However df will only execute once, so that won;t do what you want. To repeatedly execute a command put it in a loop: while : do df done If you want it to wait a while put a sleep in it, to space it out put an echo..e.g. while : do df sleep 2 echo done However, on Linux there is a program called "watch" that repeatedly executes a command an displays it on the screen updating the display "in place" .. so it does not scroll away. I am sure there must be a similar program on BSD (I would like to know as well!) but the program named "watch" on FBSD is something different. Cliff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: tail -f over NFS in -stable
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
===
RCS file: /usr/cvs/src/usr.bin/tail/forward.c,v
retrieving revision 1.15
diff -u -r1.15 forward.c
--- forward.c 2000/07/18 19:38:38 1.15
+++ forward.c 2000/09/02 16:16:40
@@ -40,7 +40,8 @@
static char sccsid[] = "@(#)forward.c 8.1 (Berkeley) 6/6/93";
#endif /* not lint */
-#include
+#include
+#include
#include
#include
#include
@@ -96,6 +97,7 @@
int action = USE_SLEEP;
struct kevent ev[2];
struct stat sb2;
+ struct statfs statfsbuf;
switch(style) {
case FBYTES:
@@ -170,7 +172,10 @@
break;
}
- if (fflag) {
+ if (statfs(fname, &statfsbuf) != 0)
+ err(1, "statfs %s", fname);
+
+ if (fflag && strcmp(statfsbuf.f_fstypename, "ufs") == 0) {
kq = kqueue();
if (kq < 0)
err(1, "kqueue");
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
FreeBSD Documentation Project /
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: tail -f over NFS in -stable
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 (kevent returns 'Operation not supported' for an NFS), so you'll just have to wait until that bit of code is MFC'd. The patch will work as a temporary fix for you though. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
