Re: ichwd problem: watchdog doesn't bark
[dropped stable@ since I'm not on it and I suspect it may not accept non-member posts] BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? My bet is on NMI, but who knows. It may depend on whether you want the BIOS, or FreeBSD, handling the interrupt. Unless you are running *very* old h/w, there's a good chance the BIOS intercepts SMI, even with a protected-mode OS running, and I wouldn't be surprised if the BIOS' response to a watchdog timeout were an immediate reboot. It might be good to check the motherboard and/or BIOS manuals. Or maybe I am trying to ask a different question. I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and our watchdog driver is careful to preserve this bit unmodified. This means that watchdog would try to cause SMI instead of NMI. On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to zero, which means that chipset would never generate an SMI. So I think this is why I don't see anything happening. Now, would should try first - reset NMI2SMI_EN to zero or set GBL_SMI_EN to 1? If you want to handle the interrupt in FreeBSD, I'd try resetting NMI2SMI_EN to zero. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RFC: small syscons and kbd patch
On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten [EMAIL PROTECTED] wrote: * Maksim Yevmenkin [EMAIL PROTECTED] wrote: the idea was to ensure that kbd-kb_locked variable only takes values 0 (zero) and 1 (one). I often use constructs like these to do that: foo = bar ? 1 : 0; Maybe !!bar is a lot shorter to write, I think the line above is a lot easier to read. Indeed. I had no idea (and I would assume that many people wouldn't in my similar level of systems programming) what in the work you were trying to do above with that line. The one-line conditional is universal in almost all major high-level language dialects I've hit, minus Python and Tcl. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ichwd problem: watchdog doesn't bark
On Fri, Dec 5, 2008 at 12:10 AM, [EMAIL PROTECTED] wrote: [dropped stable@ since I'm not on it and I suspect it may not accept non-member posts] BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? My bet is on NMI, but who knows. It may depend on whether you want the BIOS, or FreeBSD, handling the interrupt. Unless you are running *very* old h/w, there's a good chance the BIOS intercepts SMI, even with a protected-mode OS running, and I wouldn't be surprised if the BIOS' response to a watchdog timeout were an immediate reboot. It might be good to check the motherboard and/or BIOS manuals. Yeah. I just recently have embarked on an adventure of installing FreeBSD on my work T61 laptop, and while poking around the BIOS I discovered that NMI could be enabled or disabled, so I'd determine whether or not that feature is available, and see if it's turned on or off. Intel and/or the laptop vendor should be helpful in this pursuit. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten [EMAIL PROTECTED] wrote:
* Maksim Yevmenkin [EMAIL PROTECTED] wrote:
the idea was to ensure that kbd-kb_locked variable only takes values
0 (zero) and 1 (one).
I often use constructs like these to do that:
foo = bar ? 1 : 0;
Maybe !!bar is a lot shorter to write, I think the line above is a lot
easier to read.
Indeed. I had no idea (and I would assume that many people wouldn't in
my similar level of systems programming) what in the work you were
trying to do above with that line. The one-line conditional is
universal in almost all major high-level language dialects I've hit,
minus Python and Tcl.
-Garrett
The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
programming, and I would certainly expect any experienced C programmer to
recognize it.
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson [EMAIL PROTECTED] wrote:
On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten [EMAIL PROTECTED] wrote:
* Maksim Yevmenkin [EMAIL PROTECTED] wrote:
the idea was to ensure that kbd-kb_locked variable only takes values
0 (zero) and 1 (one).
I often use constructs like these to do that:
foo = bar ? 1 : 0;
Maybe !!bar is a lot shorter to write, I think the line above is a lot
easier to read.
Indeed. I had no idea (and I would assume that many people wouldn't in
my similar level of systems programming) what in the work you were
trying to do above with that line. The one-line conditional is
universal in almost all major high-level language dialects I've hit,
minus Python and Tcl.
-Garrett
The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
programming, and I would certainly expect any experienced C programmer to
recognize it.
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
2. Is it still taught in schools (I didn't learn it when I was taught
C)? If not in schools, what about the Richie text (it's sort of like
the defacto C programming standard book of course)?
3. What's the real loss of going to `? :', beyond maybe 3 extra
keystrokes if it's easier for folks who may not be as experienced to
read?
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Garrett Cooper schrieb: (I feel like I'm getting off on a bikeshed topic, but...) 1. What dialect of C was it defined in? Is it still used in the standard dialect (honestly, this is the first time I've ever seen it before, but then again I am a younger generation user)? Dialect? The ! operator is plain vanilla standard C. It takes a scalar operand and returns 1, if it compares equal to 0, otherwise it returns 0. !!, i.e. two consecutive ! operators, is one of the oldest tricks in the book, right next to (a b) - (a b) for comparison functions and countless other idioms. 3. What's the real loss of going to `? :', beyond maybe 3 extra keystrokes if it's easier for folks who may not be as experienced to read? I'd like my bikeshed grass green, please. Christoph ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, Dec 05, 2008 at 12:50:38AM -0800, Garrett Cooper wrote:
On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson [EMAIL PROTECTED] wrote:
On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten [EMAIL PROTECTED] wrote:
* Maksim Yevmenkin [EMAIL PROTECTED] wrote:
the idea was to ensure that kbd-kb_locked variable only takes values
0 (zero) and 1 (one).
I often use constructs like these to do that:
foo = bar ? 1 : 0;
Maybe !!bar is a lot shorter to write, I think the line above is a lot
easier to read.
Indeed. I had no idea (and I would assume that many people wouldn't in
my similar level of systems programming) what in the work you were
trying to do above with that line. The one-line conditional is
universal in almost all major high-level language dialects I've hit,
minus Python and Tcl.
-Garrett
The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
programming, and I would certainly expect any experienced C programmer to
recognize it.
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
The '!!x' construct is well defined in all dialects of C as far as I know.
It is after all just using the standard '!' logical negation operator twice
in a fairly straight-forward manner.
If you know what the '!' operator does it should not be too difficult to
figure out what applying it twice would do, even if one has never seen it
done that way before.
2. Is it still taught in schools (I didn't learn it when I was taught
C)? If not in schools, what about the Richie text (it's sort of like
the defacto C programming standard book of course)?
Since I did not learn C in a school I have no idea what is (or has been)
taught in schools in that regard. As for KR I must admit to never having read
it.
It is however one (of many) idiomatic constructions in C that I would not
really expect to be explicitly taught in a class. It is rather something I
would expect programmers to either come up with on their own or to encounter
when reading other peoples programs.
3. What's the real loss of going to `? :', beyond maybe 3 extra
keystrokes if it's easier for folks who may not be as experienced to
read?
An inexperienced C programmer who do not understand the '!!x' construct is
not a programmer I would count on being familiar with the '? :' operator
either. Besides, I personally find the corresponding '? :' construction
harder to read.
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon [EMAIL PROTECTED] wrote: Garrett Cooper schrieb: (I feel like I'm getting off on a bikeshed topic, but...) 1. What dialect of C was it defined in? Is it still used in the standard dialect (honestly, this is the first time I've ever seen it before, but then again I am a younger generation user)? Dialect? The ! operator is plain vanilla standard C. It takes a scalar operand and returns 1, if it compares equal to 0, otherwise it returns 0. !!, i.e. two consecutive ! operators, is one of the oldest tricks in the book, right next to (a b) - (a b) for comparison functions and countless other idioms. 3. What's the real loss of going to `? :', beyond maybe 3 extra keystrokes if it's easier for folks who may not be as experienced to read? I'd like my bikeshed grass green, please. Christoph If you really want to split hairs, ! only negates the logic value, whereas ~ actually negates the bits. So technically, you're not flipping 0 to make 1 and vice versa, but instead flipping 0 to make non-zero, etc. There is a clear distinction in hardware. The point was that !! isn't obvious at first glancing the C code. It's important for code to be readable as well as functional (that's why we have style(9)). Getting down to it I'd like to see what the compiler optimizes each as, because I can see dumb compilers saying `!!' translates to `not, bne = set, else set, continue', whereas `? :' could be translated to `bne, set, else set, continue'; I'm sure gcc has moved passed these really minute details. Hopefully this helps shed more light on where I'm coming from. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Garrett Cooper schrieb: On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon [EMAIL PROTECTED] wrote: Garrett Cooper schrieb: (I feel like I'm getting off on a bikeshed topic, but...) 1. What dialect of C was it defined in? Is it still used in the standard dialect (honestly, this is the first time I've ever seen it before, but then again I am a younger generation user)? Dialect? The ! operator is plain vanilla standard C. It takes a scalar operand and returns 1, if it compares equal to 0, otherwise it returns 0. !!, i.e. two consecutive ! operators, is one of the oldest tricks in the book, right next to (a b) - (a b) for comparison functions and countless other idioms. 3. What's the real loss of going to `? :', beyond maybe 3 extra keystrokes if it's easier for folks who may not be as experienced to read? I'd like my bikeshed grass green, please. Christoph If you really want to split hairs, ! only negates the logic value, whereas ~ actually negates the bits. So technically, you're not flipping 0 to make 1 and vice versa, but instead flipping 0 to make non-zero, etc. There is a clear distinction in hardware. I have no idea, what you are referring to. I did not even mention the bitwise complement operator ~. I just described, what ! does. I explicitely said, the operand is compared to 0. I just paraphrased, what the standard says. You can verify this by reading ISO/IEC 9899:1999 (E) §6.5.3.3:5. The point was that !! isn't obvious at first glancing the C code. It's I disagree. I sometimes even see stuff like (x ? 0 : 1) or worse (x ? false : true). I find this hard to read, because the true case returns false and vice versa. I clearly prefer a nice and concise ! or two. But today !! is not as important anymore, because C99 has a real bool type, which always is 0 or 1. See _Bool and the header stdbool.h. important for code to be readable as well as functional (that's why we have style(9)). Getting down to it I'd like to see what the compiler Don't try to argue about style(9). IMO it's horribly outdated, but there are conservative forces, which would prefer to cling to KR. At least we got function prototypes! optimizes each as, because I can see dumb compilers saying `!!' translates to `not, bne = set, else set, continue', whereas `? :' could be translated to `bne, set, else set, continue'; I'm sure gcc has moved passed these really minute details. If you use the classic approach to implement short circuit evaluation for and || you also handle !. Otherwise the code generated for stuff like if (!x || !y) would be horrible. Here's a very short explanation: You generate jump labels for the true and false cases. When traversing a logical expression and encountering a !, you just swap the true and false jump labels - nothing more happens for a !. So at no point you generate code, which produces a 0/1 and compares it again. While evaluating a logical expression with short circuit evaluation, there are no intermediate 0 and 1 constants involved at all. This is a very simpel model. Modern optimizing compilers do not generate code directly from the abstract syntax tree, but use a intermediate representation, which is more suited for optimization[1][2]. Hopefully this helps to shed a bit light on compiler construction. Christoph [1] (self advertisement) FIRM is a modern graph based IR, which uses SSA form: http://www.libfirm.org/ [2] LLVM has a nice IR, too: http://www.llvm.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Garrett Cooper [EMAIL PROTECTED] writes: If you really want to split hairs, ! only negates the logic value, whereas ~ actually negates the bits. So technically, you're not flipping 0 to make 1 and vice versa, but instead flipping 0 to make non-zero, etc. There is a clear distinction in hardware. He didn't say anything about flipping bits... and you're wrong, !0 is guaranteed to evaluate to 1. The point was that !! isn't obvious at first glancing the C code. It is to an experienced C programmer. Getting down to it I'd like to see what the compiler optimizes each as, because I can see dumb compilers saying `!!' translates to `not, bne = set, else set, continue', whereas `? :' could be translated to `bne, set, else set, continue'; I'm sure gcc has moved passed these really minute details. Never try to second-guess the compiler. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ichwd problem: watchdog doesn't bark
Andriy Gapon [EMAIL PROTECTED] writes: When I start watchdogd I see the following messages: timer enabled timeout set to 28 ticks and then a flow of messages: timer reloaded Then I kill -9 watchdogd. timer reloded messages are no longer produced. And there are no other messages. But nothing happens for many minutes that I waited. The watchdog may be disabled, either in hardware or by the BIOS at boot time, but the driver should have detected that. It is also possible that the BIOS catches the SMI but ignores it. BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? It should fire SMI, IIRC. Read the comments at the top of the code for references to the relevant Intel documentation, which you can download for free. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Christoph Mallon [EMAIL PROTECTED] writes: Don't try to argue about style(9). IMO it's horribly outdated, but there are conservative forces, which would prefer to cling to KR. At least we got function prototypes! If there's something specific in style(9) you don't like, you are welcome to start a discussion about it, and we will consider the merits of your arguments; talking about conservative forces that would prefer to cling to KR will get you nowhere. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
on 05/12/2008 10:50 Garrett Cooper said the following:
On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson [EMAIL PROTECTED] wrote:
On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten [EMAIL PROTECTED] wrote:
* Maksim Yevmenkin [EMAIL PROTECTED] wrote:
the idea was to ensure that kbd-kb_locked variable only takes values
0 (zero) and 1 (one).
I often use constructs like these to do that:
foo = bar ? 1 : 0;
Maybe !!bar is a lot shorter to write, I think the line above is a lot
easier to read.
Indeed. I had no idea (and I would assume that many people wouldn't in
my similar level of systems programming) what in the work you were
trying to do above with that line. The one-line conditional is
universal in almost all major high-level language dialects I've hit,
minus Python and Tcl.
-Garrett
The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
programming, and I would certainly expect any experienced C programmer to
recognize it.
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
I am not sure what you meant by dialect of C, just in case you meant
something different from others understood here's my personal
observation: you will quite a bit of '!!' in Linux kernel code, you
would see much much fewer of them in our code.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 qemu completely broken?
Nate Eldredge [EMAIL PROTECTED] wrote on 4 Dec 2008 14:43: ... pain to clean up. '-net tap' works fine, but requires root privileges and No. is more work to set up. Yes, and this must be as root, but you can use later the tap device as unprivileged user. (Isn't it a virtual network jack, where you can plug into your cable? ;-) -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Garret,
Fri, Dec 05, 2008 at 12:50:38AM -0800, Garrett Cooper wrote:
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
It is the standard negation operator: !(expr) is equal to (expr == 0).
2. Is it still taught in schools (I didn't learn it when I was taught
C)?
Yes. I am personally teaching the people in school and I am explaining
the concept of double negation every two years ;))
If not in schools, what about the Richie text (it's sort of like
the defacto C programming standard book of course)?
KR book is good but it at no means covers all tricks and idioms
of a C language.
3. What's the real loss of going to `? :', beyond maybe 3 extra
keystrokes if it's easier for folks who may not be as experienced to
read?
No real loss, just easier to type and looks more compact. It is the
matter of a personal taste, I think.
If one knows this idiom, he will recognize it at a glance. If not, one
should think a bit about the logics behind it, but it shouldn't be hard:
almost everyone uses constructs like 'if (!ptr)'. And there is only one
step from there to the double negation.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpsI9cudOk9G.pgp
Description: PGP signature
IPMI shared ethernet ports (again).
I posted here a month or two ago about being amazed that some system management cards can share a physical ethernet port. Some of you responded that it doesn't always work. Well... I've encountered this and I'm wondering if I can work around it somehow. The ones that work are in Dell 1950-III servers (The R-200 seem to work, too). They have bce driver ports. The HP DL/360 that I have here today have bge driver ports and the IPMI console appears to stop working just as soon as FreeBSD probes the port. Is this something that can be configured in BGE or is it just not going to work? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, 5 Dec 2008, Garrett Cooper wrote:
On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon
[EMAIL PROTECTED] wrote:
Garrett Cooper schrieb:
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
Dialect? The ! operator is plain vanilla standard C. It takes a scalar
operand and returns 1, if it compares equal to 0, otherwise it returns 0.
!!, i.e. two consecutive ! operators, is one of the oldest tricks in the
book, right next to (a b) - (a b) for comparison functions and countless
other idioms.
3. What's the real loss of going to `? :', beyond maybe 3 extra
keystrokes if it's easier for folks who may not be as experienced to
read?
I'd like my bikeshed grass green, please.
Christoph
If you really want to split hairs, ! only negates the logic value,
whereas ~ actually negates the bits. So technically, you're not
flipping 0 to make 1 and vice versa, but instead flipping 0 to make
non-zero, etc. There is a clear distinction in hardware.
The point was that !! isn't obvious at first glancing the C code. It's
important for code to be readable as well as functional (that's why we
have style(9)). Getting down to it I'd like to see what the compiler
optimizes each as, because I can see dumb compilers saying `!!'
translates to `not, bne = set, else set, continue', whereas `? :'
could be translated to `bne, set, else set, continue'; I'm sure gcc
has moved passed these really minute details.
Out of curiosity, I tried some various compilers, including gcc on i386,
amd64, and sparc; Intel's C compiler on i386; tcc (tiny, non-optimizing C
compiler) on i386; and Sun's compiler (old version) on sparc.
I compiled the following file:
int bangbang(int x) { return !!x; }
int ternary(int x) { return x ? 1 : 0; }
Intel's compiler generated different code for these two functions when
optimization was turned off. bangbang used a conditional set instruction,
while ternary used conditional jumps. With optimization on the two were
identical.
All other compilers generated identical code for the two functions whether
optimization was on or off. (Of course, the generated code varied between
compilers; tcc's in particular was decidedly non-optimized.)
I really don't think something as simple as this is worth worrying about
in terms of code efficiency. Even if they weren't identical, the
difference is at most a couple of instructions and a pipeline flush, and
if that's a serious problem you need to be using assembly anyway.
Besides, it's not a piece of code that comes up all that often.
The only basis for arguing about it is style, and I think we've
established that it's purely a matter of taste. In particular, there
isn't a clear favorite for which is easier to read. IMHO, style(9) should
remain agnostic and let the programmer decide.
However, if people really feel that consistency is necessary here, I
propose the following: if the cents digit of the closing price of the Dow
Jones Industrial Average on this coming Monday, December 8, 2008, is even,
then style(9) shall be edited to indicate that `!!x' is preferred. If
odd, then style(9) shall prefer `x ? 1 : 0'.
:-)
--
Nate Eldredge
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
Nate Eldredge wrote:
int bangbang(int x) { return !!x; }
int ternary(int x) { return x ? 1 : 0; }
Stylewise, I prefer
int notzero(int x) { return x!=0; }
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: small syscons and kbd patch
On Fri, 5 Dec 2008, Stephen Montgomery-Smith wrote:
Nate Eldredge wrote:
int bangbang(int x) { return !!x; }
int ternary(int x) { return x ? 1 : 0; }
Stylewise, I prefer
int notzero(int x) { return x!=0; }
icc -O0 compiles notzero the same as bangbang (better than ternary). tcc
produces better code for notzero than the other two. Sun cc without
optimization produces slightly better code for notzero than the other two
(one jump instead of two). For everything else all three produce
equivalent code.
`x 1' and `x || 0' are some other possibilities.
Anyway, maybe there is something more useful we could all be doing. :)
--
Nate Eldredge
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Small change to wc
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD, we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
equivalent to the Linux -L. This flag tells wc to keep track of the longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD, we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
equivalent to the Linux -L. This flag tells wc to keep track of the longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote: Hello everyone, In the process of migrating the last of a few Linux servers to FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD wc didn't have an equivalent to the Linux -L. This flag tells wc to keep track of the longest line in the input. Here's a little diff to add this functionality to BSD wc. [..] What's the plus side of having this? I can accomplish the same with something like awk without the additional overhead, which would be guaranteed to be portable. s/overhead/overhead to wc/. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
What's the problem having it? The total code is mere bytes and it eases the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply, too)
but it doesn't hurt to explore options. Additionally, with awk, you can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD,
we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have
an
equivalent to the Linux -L. This flag tells wc to keep track of the
longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows
the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
What's the problem having it? The total code is mere bytes and it eases the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply, too)
but it doesn't hurt to explore options. Additionally, with awk, you can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD,
we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have
an
equivalent to the Linux -L. This flag tells wc to keep track of the
longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows
the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
pgpg0pOPT2vKC.pgp
Description: PGP signature
Re: Small change to wc
Garrett Cooper wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD, we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
equivalent to the Linux -L. This flag tells wc to keep track of the longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
true, but this is a well known extension that people use and to tell
the truth, I have no idea how I would do it in awk without reading a
lot where in wc it's obvious from the synopsis.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
What's the problem having it? The total code is mere bytes and it eases the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply, too)
but it doesn't hurt to explore options. Additionally, with awk, you can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD,
we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have
an
equivalent to the Linux -L. This flag tells wc to keep track of the
longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that shows
the
length of the longest line
My apologies if this is in the wrong format. I don't often post here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
Very true. Ok, I've been easily won over :).
The patch looks largely ok, but have you gone through compiling it in
your own dev tree (vatting out possible warnings, etc).
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
I've successfully built it in multiple circumstances. The only thing I'm
worried about (I'm on the road now and can't test) is what will occur if wc
is fed a zero-length input... ie, a touched file or a echo | wc -L.
On Fri, Dec 5, 2008 at 3:23 PM, Garrett Cooper [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov [EMAIL PROTECTED]
wrote:
On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
What's the problem having it? The total code is mere bytes and it eases
the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply,
too)
but it doesn't hurt to explore options. Additionally, with awk, you
can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather
run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED]
wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED]
wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to
FreeBSD,
we
ran in to a bit of a snag with one of our scripts when BSD wc didn't
have
an
equivalent to the Linux -L. This flag tells wc to keep track of the
longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that
shows
the
length of the longest line
My apologies if this is in the wrong format. I don't often post
here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt =
tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
Very true. Ok, I've been easily won over :).
The patch looks largely ok, but have you gone through compiling it in
your own dev tree (vatting out possible warnings, etc).
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Sat, 6 Dec 2008 01:14:58 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
What's the problem having it? The total code is mere bytes and it eases the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply, too)
but it doesn't hurt to explore options. Additionally, with awk, you can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.
Real argument con is that you're making life easier on users of
GNU/Linux software whose authors ought to be taught how to write
portable code.
I think compatibility with GNU/Linux is a miserable reason for
bloating software on BSD - especially considering how NU the typical
GNU/Linux extensions are. However, this seems like a useful feature in
and of itself, and fits in well with the command it's being added to.
So adding it - and adding it to wc - seem like reasonable things. And
if we're going to add a feature to a command, making it compatible
with an existing implementation seems like a good idea.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, 5 Dec 2008 14:14:32 -0800, Sheldon Givens [EMAIL PROTECTED] wrote: Hello everyone, In the process of migrating the last of a few Linux servers to FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD wc didn't have an equivalent to the Linux -L. This flag tells wc to keep track of the longest line in the input. Here's a little diff to add this functionality to BSD wc. With this patch, an additional parameter is added to output that shows the length of the longest line Adding the option to increase finger-compatibility and make shell scripts a bit easier to port over sounds fine by me :) My apologies if this is in the wrong format. I don't often post here. ---snip--- [patch] ---unsnip--- Can you post a `diff -u' or `diff -c' version of the patch? I like the idea of the new option but it would be easier to read in -u/-c format. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
New diff -u:
--- /usr/src/usr.bin/wc/wc.c2004-12-27 14:27:56.0 -0800
+++ wc/wc.c 2008-12-05 14:33:21.0 -0800
@@ -62,8 +62,8 @@
#include wchar.h
#include wctype.h
-uintmax_t tlinect, twordct, tcharct;
-int doline, doword, dochar, domulti;
+uintmax_t tlinect, twordct, tcharct, tlongline;
+int doline, doword, dochar, domulti, dolongline;
static int cnt(const char *);
static voidusage(void);
@@ -75,7 +75,7 @@
(void) setlocale(LC_CTYPE, );
- while ((ch = getopt(argc, argv, clmw)) != -1)
+ while ((ch = getopt(argc, argv, clmwL)) != -1)
switch((char)ch) {
case 'l':
doline = 1;
@@ -91,6 +91,9 @@
domulti = 1;
dochar = 0;
break;
+ case 'L':
+ dolongline = 1;
+ break;
case '?':
default:
usage();
@@ -125,6 +128,8 @@
(void)printf( %7ju, twordct);
if (dochar || domulti)
(void)printf( %7ju, tcharct);
+ if (dolongline)
+ (void)printf( %7ju, tlongline);
(void)printf( total\n);
}
exit(errors == 0 ? 0 : 1);
@@ -134,7 +139,7 @@
cnt(const char *file)
{
struct stat sb;
- uintmax_t linect, wordct, charct;
+ uintmax_t linect, wordct, charct, llcnt, tmpll;
int fd, len, warned;
size_t clen;
short gotsp;
@@ -143,7 +148,7 @@
wchar_t wch;
mbstate_t mbs;
- linect = wordct = charct = 0;
+ linect = wordct = charct = llcnt = tmpll = 0;
if (file == NULL) {
file = stdin;
fd = STDIN_FILENO;
@@ -167,9 +172,13 @@
return (1);
}
charct += len;
- for (p = buf; len--; ++p)
- if (*p == '\n')
+ for (p = buf; len--; ++p)
+ if (*p == '\n') {
+ if (tmpll llcnt)
+ llcnt = tmpll;
+ tmpll = 0;
++linect;
+ } else {tmpll++;}
}
tlinect += linect;
(void)printf( %7ju, linect);
@@ -177,6 +186,10 @@
tcharct += charct;
(void)printf( %7ju, charct);
}
+ if (dolongline) {
+ tlongline = llcnt;
+ (void)printf( %7ju, tlongline);
+ }
(void)close(fd);
return (0);
}
@@ -194,7 +207,7 @@
(void)printf( %7lld, (long
long)sb.st_size);
tcharct += sb.st_size;
(void)close(fd);
- return (0);
+ return (0);
}
}
}
@@ -229,10 +242,15 @@
else if (clen == 0)
clen = 1;
charct++;
+ tmpll++;
len -= clen;
p += clen;
- if (wch == L'\n')
+ if (wch == L'\n') {
+ if (tmpll llcnt)
+ llcnt = tmpll;
+ tmpll = 0;
++linect;
+ }
if (iswspace(wch))
gotsp = 1;
else if (gotsp) {
@@ -256,6 +274,10 @@
tcharct += charct;
(void)printf( %7ju, charct);
}
+ if (dolongline) {
+ tlongline = llcnt;
+ (void)printf( %7ju, llcnt - 1);
+ }
(void)close(fd);
return (0);
}
@@ -263,6 +285,6 @@
static void
usage()
{
- (void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
+ (void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
exit(1);
}
On Fri, Dec 5, 2008 at 4:17 PM, Giorgos Keramidas
[EMAIL PROTECTED]wrote:
On Fri, 5 Dec 2008 14:14:32 -0800, Sheldon Givens [EMAIL PROTECTED]
wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to
FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD
wc didn't have an equivalent to the Linux -L. This flag tells wc to
keep track of the longest line in the input.
Re: Small change to wc
On Fri, Dec 5, 2008 at 3:28 PM, Sheldon Givens [EMAIL PROTECTED] wrote:
I've successfully built it in multiple circumstances. The only thing I'm
worried about (I'm on the road now and can't test) is what will occur if wc
is fed a zero-length input... ie, a touched file or a echo | wc -L.
On Fri, Dec 5, 2008 at 3:23 PM, Garrett Cooper [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov [EMAIL PROTECTED]
wrote:
On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
What's the problem having it? The total code is mere bytes and it eases
the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply,
too)
but it doesn't hurt to explore options. Additionally, with awk, you
can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to wc -clwL in awk? Would you really rather
run
wc -clw awk '{if(lengthx){x=length}}END{if(x0){print x}else{print
0}}'`?
Isn't wc -L a more elegant solution than awk
'{if(lengthx){x=length}}END{if(x0){print x}else{print 0}}'`?
Should I continue?
Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.
On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper [EMAIL PROTECTED]
wrote:
On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens [EMAIL PROTECTED]
wrote:
Hello everyone,
In the process of migrating the last of a few Linux servers to
FreeBSD,
we
ran in to a bit of a snag with one of our scripts when BSD wc
didn't have
an
equivalent to the Linux -L. This flag tells wc to keep track of the
longest
line in the input.
Here's a little diff to add this functionality to BSD wc.
With this patch, an additional parameter is added to output that
shows
the
length of the longest line
My apologies if this is in the wrong format. I don't often post
here.
Happy Holidays,
Sheldon Givens
---snip---
65,66c65,66
uintmax_t tlinect, twordct, tcharct;
int doline, doword, dochar, domulti;
---
uintmax_t tlinect, twordct, tcharct, tlongline;
int doline, doword, dochar, domulti, dolongline;
78c78
while ((ch = getopt(argc, argv, clmw)) != -1)
---
while ((ch = getopt(argc, argv, clmwL)) != -1)
93a94,96
case 'L':
dolongline = 1;
break;
127a131,132
if (dolongline)
(void)printf( %7ju, tlongline);
137c142
uintmax_t linect, wordct, charct;
---
uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
linect = wordct = charct = 0;
---
linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
if (*p == '\n')
---
if (*p == '\n') {
if (tmpll llcnt)
llcnt =
tmpll;
tmpll = 0;
172a181
} else { tmpll++; }
179a189,192
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, tlongline);
}
197c210
return (0);
---
return (0);
231a245
tmpll++;
234c248,251
if (wch == L'\n')
---
if (wch == L'\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
235a253
}
258a277,280
if (dolongline) {
tlongline = llcnt;
(void)printf( %7ju, llcnt - 1);
}
266c288
(void)fprintf(stderr, usage: wc [-clmw] [file ...]\n);
---
(void)fprintf(stderr, usage: wc [-clmwL] [file ...]\n);
---unsnip---
What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
Very true. Ok, I've been easily won over :).
The patch looks largely ok, but have you gone through compiling it in
your own dev tree (vatting out possible warnings, etc).
-Garrett
1. Please don't top-post.
2. Solving the problem is easy. Have the value default to something
unrealistic (like -1) and simply, set the value to 0, if indeed the
value is 0.
Cheers,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
