On Feb 02 11:49:50, stu.li...@spacehopper.org wrote:
> On 2022-02-02, Jan Stary wrote:
> > #define noreturn __dead
> > #else
> > #include
> > #endif
> >
> > and stdnoreturn.h indeed does not exist.
>
> Where are you looking? It should be in
>
On 2022-02-02, Jan Stary wrote:
> #define noreturn __dead
> #else
> #include
> #endif
>
> and stdnoreturn.h indeed does not exist.
Where are you looking? It should be in
/usr/lib/clang/13.0.0/include/stdnoreturn.h.
Builds fine for me.
Jan Stary wrote:
> This is current/armv7 on a Beagle Bone Black (dmesg below).
> make build just failed in usr.bin/awk with
>
> ===> usr.bin/awk
> yacc -o awkgram.tab.c -d /usr/src/usr.bin/awk/awkgram.y
> /usr/src/usr.bin/awk/awkgram.y: yacc finds 62 s
This is current/armv7 on a Beagle Bone Black (dmesg below).
make build just failed in usr.bin/awk with
===> usr.bin/awk
yacc -o awkgram.tab.c -d /usr/src/usr.bin/awk/awkgram.y
/usr/src/usr.bin/awk/awkgram.y: yacc finds 62 shift/reduce conflicts
/usr/src/usr.bin/awk/awkgram.y: yacc finds
@@ The terms of this license are identical
Additionally, OpenBSD includes some other ATT code with
non-restrictive
copyrights, such as the reference implementation of
-http://cm.bell-labs.com/cm/cs/who/bwk/awk.tar.gz;>awk.
+https://github.com/onetrueawk/awk;>awk.
Caldera
? awk.diff
Index: polic
with a fragment from a line written by process #1, followed by
> >> lines from process #2, followed by the remainder of the line from
> >> #1, etc.
> >>
> >> --
> >> Christian "naddy" Weisgerber na...@mips.inka.de
> &
; --
>> Christian "naddy" Weisgerber na...@mips.inka.de
>>
> Right, a fflush() call after the printf makes the issue go away, but
> only since awk is being nice and issues a single write call for that
> single printf. Since awk afaik does not give such
end
> up with a fragment from a line written by process #1, followed by
> lines from process #2, followed by the remainder of the line from
> #1, etc.
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Right, a fflush() call after
Jordan Geoghegan:
> --- /tmp/bad.txt Wed Apr 14 21:06:51 2021
> +++ /tmp/good.txt Wed Apr 14 21:06:41 2021
I'll note that no characters have been lost between the two files.
Only the order is different.
> The only thing that changed between these runs was me using either xargs -P 1
> or -P
Hello,
I've found some very interesting behaviour when subjecting various awk
implementations to some very specific circumstances.
I'm basically looking for a sanity check here to confirm if I'm just wildly
flailing, or if I am indeed onto something here.
Here's my situation:
When parsing
On Mon, 13 Jul 2020 13:02:44 +0200, Jan Stary wrote:
> This is current/amd64.
>
> On UTF input, awk segfaults when using a multi-character RS:
>
> $ cat /tmp/in
> č
>
> $ hexdump -C /tmp/in
> c4 8d 0a|...|
> 00
This is current/amd64.
On UTF input, awk segfaults when using a multi-character RS:
$ cat /tmp/in
č
$ hexdump -C /tmp/in
c4 8d 0a |...|
0003
$ cat /tmp/in | awk '{print$1}'
č
$ cat /tmp/in | awk -v RS=x '{print$1}'
č
$ cat /tmp/in | awk
I be reporting this bug upstream, or are
you planning on upstreaming a diff?
I've created a pull request to fix this upstream:
https://github.com/onetrueawk/awk/pull/80
- todd
Sorry for the late reply, I've been AFK for the last week.
Excited to see base system awk get synced
Should I be reporting this bug upstream, or are
>>> you planning on upstreaming a diff?
>> I've created a pull request to fix this upstream:
>> https://github.com/onetrueawk/awk/pull/80
>>
>> - todd
>
> Sorry for the late reply, I've been AFK for the
created a pull request to fix this upstream:
https://github.com/onetrueawk/awk/pull/80
- todd
Sorry for the late reply, I've been AFK for the last week.
Excited to see base system awk get synced with upstream. Kudos to you
and Philip for such a swift and effective response.
Regards
upstream:
https://github.com/onetrueawk/awk/pull/80
- todd
<mailto:zel...@zeloff.org>> wrote:
On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> I'm working on a simple awk snippet to convert the IP range data
listed in
> the Extended Delegation Statistics data from ARIN [1] and
convert it into
&
On Sat, 06 Jun 2020 18:16:39 -0900, Philip Guenther wrote:
> Todd, are we up to date with upstream, or is this latent there too?
We are not up to date but upstream (https://github.com/onetrueawk/awk)
exhibits the same bug.
- todd
I was halfway there.
That's an old bug.
Philip Guenther wrote:
> On Sat, Jun 6, 2020 at 5:08 PM Zé Loff wrote:
>
> > On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> > > I'm working on a simple awk snippet to convert the IP range data listed
>
On Sat, Jun 6, 2020 at 5:08 PM Zé Loff wrote:
> On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> > I'm working on a simple awk snippet to convert the IP range data listed
> in
> > the Extended Delegation Statistics data from ARIN [1] and convert it into
>
On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> Hello,
>
> I was hoping the fine folks here could give me a quick sanity check, I'm by
> no means an awk guru, so I'm likely missing something obvious. I wanted to
> ask here quickly before I started flapping
Hello,
I was hoping the fine folks here could give me a quick sanity check, I'm
by no means an awk guru, so I'm likely missing something obvious. I
wanted to ask here quickly before I started flapping my gums on bugs@.
I'm working on a simple awk snippet to convert the IP range data listed
e.
>
> After a few minutes running and just ~1.7MiB of HTML downloaded, it
> tried to recurse into a lot of non-existing directories, so I cut it
> short there. The figure may not be perfect.
>
> $ grep -E '[0-9]$' everything.html | sed 's|.* \([0-9]*\)$|\1|' | awk
> '{sum+=$1} END{pr
rt there. The figure may not be perfect.
$ grep -E '[0-9]$' everything.html | sed 's|.* \([0-9]*\)$|\1|' | awk
'{sum+=$1} END{print sum / 1024 / 1024}'
65629
The sum of all filesizes, which are listed in kebibytes, divided by
1024^2, to turn it into gibibytes, returns 65629 gibibytes or about
65 tebib
nger used by a port.
> $ egrep '[0-9]$' distfiles.txt | sed 's|.* \([0-9]*\)$|\1|' | awk '{
> sum += $1 / 10 } END { print sum "G" }'
> 54.8126G
>
> Most of space is taken by distfiles which are at least 100 MB big:
>
> $ egrep '[0-9]{9}$' distfiles.txt | sed 's|.*
I was lucky with HTML layout which allowed me to go
> straightforward:
>
> $ egrep '[0-9]$' distfiles.txt | sed 's|.* \([0-9]*\)$|\1|' | awk '{
> sum += $1 / 10 } END { print sum "G" }'
> 54.8126G
>
> Most of space is taken by distfiles which are at least 100
On Thu, Dec 26, 2019 at 04:13:33PM +, goleo . wrote:
> Most of them are games, but what is Linux 4.20 kernel doing here?
sysutils/dtb
I was lucky with HTML layout which allowed me to go
> straightforward:
>
> $ egrep '[0-9]$' distfiles.txt | sed 's|.* \([0-9]*\)$|\1|' | awk '{
> sum += $1 / 10 } END { print sum "G" }'
> 54.8126G
>
> Most of space is taken by distfiles which are at least 100
grep '[0-9]$' distfiles.txt | sed 's|.* \([0-9]*\)$|\1|' | awk '{
sum += $1 / 10 } END { print sum "G" }'
54.8126G
Most of space is taken by distfiles which are at least 100 MB big:
$ egrep '[0-9]{9}$' distfiles.txt | sed 's|.* \([0-9]*\)$|\1|' | awk
'{ sum += $1 / 10
to eliminate -0 results in T.expr, which
has irritated me for 20+ years.
[1]
https://github.com/danfuzz/one-true-awk/blob/master/versions/2012-12-20/FIXES
On Thu, Oct 19, 2017 at 1:14 PM, Niels Kobschaetzki
<ni...@kobschaetzki.net> wrote:
>
>> On 19. Oct 2017, at 06:23, flipchan <f
i'm watching a bunch of losers who argue before running diff
> You didn't really make a great case for the newer awk, either. Is there a
> good reason to use the 2012 release from upstream? If so, you could submit
> a diff and explain the benefits.
>
> On Oct 19, 2017 1
You didn't really make a great case for the newer awk, either. Is there a
good reason to use the 2012 release from upstream? If so, you could submit
a diff and explain the benefits.
On Oct 19, 2017 12:15 AM, "Niels Kobschaetzki" <ni...@kobschaetzki.net>
wrote:
> On 19.
> On 19. Oct 2017, at 06:23, flipchan <flipc...@riseup.net> wrote:
>
> Yeah blindly follow the flow of the others , DONT THINK SO
That doesn’t explain the reasoning WHY the newer awk is not used.
>> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas
>> <de
from outside
>suppliers:
>Awk Aug 10, 2011 version
>This turns out to be one release behind upstream, where the latest
>release is from December 20 2012: a quick check shows that
>DragonFlyBSD, FreeBSD, and NetBSD all use this version.
>
>Just out of curiosity, is there a reason w
On the 6.2 release page, and confirmed in the source code, one can see
The system includes the following major components from outside suppliers:
Awk Aug 10, 2011 version
This turns out to be one release behind upstream, where the latest
release is from December 20 2012: a quick check shows
I wrote:
[...] Why should
be difficult to track the indices in yytext of the beginning and the end
of each matching subexpression, in two arrays of integers (one for
the beginning and one for the end)? [...]
More exactly: in the first array the index of the first element of
the matching
Otto Moerbeek o...@drijf.net wrote:
Refering to subpatterns is not available in flex. I suppose it is not
available since it would require a more complex re engine.
Interpretation of the lexical value should be hand-crafted.
I also though caomplexity can be the reason, but I have doubts.
On Mon, Jun 08, 2015 at 02:49:44PM +, hru...@gmail.com wrote:
Otto Moerbeek o...@drijf.net wrote:
Tradiotionally, { } pattersn are not part of awk re's.
Posix added them, but we do not include them afaik. Gnu awk only accepts
them if given an extra arg (--posix or --re-interval
Otto Moerbeek o...@drijf.net wrote:
Tradiotionally, { } pattersn are not part of awk re's.
Posix added them, but we do not include them afaik. Gnu awk only accepts
them if given an extra arg (--posix or --re-interval).
I think this should be documented.
Although there is a clear theory
On Thu, May 28, 2015 at 02:08:47AM -0500, cwl...@mst.edu wrote:
Hi misc,
I'm running a 5.7 release, and I'm wondering if anyone can confirm
an awk bug I found.
Curly brackets are treated as literal characters instead of bounds
as specified by re_format(7).
Reproduction:
echo aa
Hi misc,
I'm running a 5.7 release, and I'm wondering if anyone can confirm
an awk bug I found.
Curly brackets are treated as literal characters instead of bounds
as specified by re_format(7).
Reproduction:
echo aa | awk '/a{2}/'
produces no output instead of printing aa as expected.
echo
Here is a simple sine wave generator in awk.
It produces 1 second of a 1000 Hz sine wave
scaled to an amplitude of 24 bits, at 44100Hz.
The individual 24bit samples are printed out
as three bytes, from lowest to highest.
$ cat sin.awk
BEGIN {
tone = 1000;
duration = 1
On Thu, Jan 15, 2009 at 02:41:24PM +, Andreas Kahari spoke thusly:
2009/1/15 igor denisov denisovigor1...@rambler.ru:
Hi there
Can not understand.
input:
34523 9348 98493 82983
9485 83928 9283 9283
394 39934 293 8347
3456 9238 9283 9283
awk 'NR==1 { for (i = 1; i = NF; i
394 39934 293 8347
3456 9238 9283 9283
awk 'NR==1 { for (i = 1; i = NF; i++) {n=$i; next}}; {n-=$i} END {print
n}'
input
output:
21188 it is first column, why?
You should really take these questions to an awk forum, not to this
mailing list.
Your program reads
Hello there.
There is a problem here.
input:
34523
9485
394
3456
awk '{subtruct-=$1} END {print subtruct}' input
output:
-47858
same thing but without minus with
awk '{sum+=$1} END {print sum}' input
output:
47858
Why in both cases the code sums the field?
--
igor denisov.
2009/1/15 igor denisov denisovigor1...@rambler.ru:
Hello there.
There is a problem here.
input:
34523
9485
394
3456
awk '{subtruct-=$1} END {print subtruct}' input
output:
-47858
same thing but without minus with
awk '{sum+=$1} END {print sum}' input
output:
47858
Why
2009/1/15 igor denisov denisovigor1...@rambler.ru:
Hi there
Can not understand.
input:
34523 9348 98493 82983
9485 83928 9283 9283
394 39934 293 8347
3456 9238 9283 9283
awk 'NR==1 { for (i = 1; i = NF; i++) {n=$i; next}}; {n-=$i} END {print n}'
input
output:
21188 it is first column
.
input:
34523
9485
394
3456
awk '{subtruct-=$1} END {print subtruct}' input
output:
-47858
same thing but without minus with
awk '{sum+=$1} END {print sum}' input
output:
47858
Why in both cases the code sums the field?
--
igor denisov.
Our awk do not recognize range regex operator ({n,m} syntax). But man
page says:
awk supports extended regular expressions (EREs). See re_format(7) for
more information on regular expressions.
This behavior is same as in FreeBSD. gawk recognize range operator in
POSIX mode (--posix).
As far
On Thu, Sep 04, 2008 at 12:35:20PM +0400, Vadim Zhukov wrote:
Our awk do not recognize range regex operator ({n,m} syntax). But man
page says:
awk supports extended regular expressions (EREs). See re_format(7) for
more information on regular expressions.
This behavior is same
Hello.
Just a though... I was writing a simple awk(1) script and looked
at the options supported by this utility in the hope to make the code
cleaner. It seems that there is a big difference between the synopsis
in the manual page:
awk [-safe] [-V] [-d[n]] [-F fs] [-v var=value] [prog | -f
On Mon, Jan 29, 2007 at 07:37:04PM +0100, Igor Sobrado wrote:
As a second change, I would suggest changing the usage message
in the binary to fit on a standard 80 columns display. In short,
I propose:
- synchronizing the usage message returned by awk(1) and the
synopsis
Looking carefully at the switch () {...} structure in main.c
it seems that the option -f requires an argument: iff the argument
to -f is optional I would write:
awk [-sae] [-V] [-d[n]] [-F fs] [-v var=value] [prog | -f [progfile]]
file ...
But it does not look as an optional argument
Jason, you are very fast!
I will download the new main.c as soon as I arrive at home and remove
the case for the -m option. I will remove the f option in [-safe]
as it seems that the argument to it is not optional.
I will submit the patch, based on the updated code, later. Two changes:
-
On Mon, Jan 29, 2007 at 09:11:26PM +0100, Igor Sobrado wrote:
Looking carefully at the switch () {...} structure in main.c
it seems that the option -f requires an argument: iff the argument
to -f is optional I would write:
awk [-sae] [-V] [-d[n]] [-F fs] [-v var=value] [prog | -f [progfile
, that is now managed by the default case:
# awk -mr
awk: unknown option -mr ignored
awk: no program given
The second one fixes the man page for awk.1:
--- awk.1 Mon Jan 29 15:01:15 2007
+++ awk.1 Mon Jan 29 15:01:30 2007
@@ -31,7 +31,7 @@
.Nd pattern-directed
without argument -s, -a, -f, -e in both main.c
and the manual page for awk(1).
Hope you will like this change too. Feel free to change the
patch if you do not like it; I believe that removing the f
option on -safe is good, but I can be wrong.
Best wishes,
Igor.
| -f [progfile]] but I
believe that it is not optional, but required. In any case,
the f option in -safe seems superfluous.
The patches submitted remove the f option in the block of
options without argument -s, -a, -f, -e in both main.c
and the manual page for awk(1).
Hope you will like
:
# awk -mr
awk: unknown option -mr ignored
awk: no program given
hmm, i don;t see the harm of flagging these as obsoleted...the output is
very similar whatever way you do it, and at least this way people used
to the old behaviour get a little more warning.
additionally
In a private email, Philip Guenther has observed that awk does not
completely folow the POSIX option guidelines. [-safe] is not
[-s,-a,-f,-e] but a single option!
The right patch is then:
--- main.c.orig Mon Jan 29 15:01:20 2007
+++ main.c Mon Jan 29 15:52:47 2007
@@ -64,7 +64,7
On Mon, Jan 29, 2007, Jason McIntyre wrote:
ah, ok. it is not 4 options (-s, -a, -f, and -e), but one (-safe, as in
not in danger). that's why it is described as a ...first (and not
very reliable) approximation to a ``safe'' version of awk.
you are confusing that with the -f option, which
On Mon, Jan 29, 2007 at 11:19:11PM +0100, Igor Sobrado wrote:
I can send the patches to Brian Kernighan, asking him to apply
these changes to the awk(1) source code. Do you agree? If you
prefer sending the patches yourself, let me know.
the changes will be sent upstream next time we
62 matches
Mail list logo
