This is just a little script I wrote to renumber Khavi's library, because the labels change almost every time I make a major change to it. Basically, you use the standard Awk/gawk invocation to run it (awk -f awk_script input_file > output_file).

However, it doesn't renumber all of the labels in a program. Everything to be renumbered must be after a line containing "StartAwk" and before a line containing "EndAwk". The tags can be used multiple times in a file without problems.

All lines to be renumbered must be matched by the regex "[0-9]+:". Here's an example file:




Code:


The output file will look like this:


Code:




Hope it's useful to someone.

awk_script

Very nice, thanks for sharing! I didn't know that anyone actually wrote Awk scripts anymore other than short snippets to split lines.

Awk is awesome. I use it in the Punix build system to generate source code from a master source file. I guess you could call it a short snippet at only 80 lines long, for large values of "short".

Heck, a couple years ago I wrote a small awk script that was also a valid C program (which also produced the same output when run as either language). It's nice that C and awk have nearly-identical printf() functions.

Very impressive; I didn't realize they were quite that close. Sounds like I need to look more closely at some of the things that awk can do besides splitting things one of these days, then.

Only if you really exploited that # is a comment in AWK to wield some crazy macro magic in C.



Not really. If you find yourself about to actually write an AWK script, just switch to Python at that point. AWK is really just good for the splitting stuff that everyone uses it for.

Last time I did something with awk I later realized I could have done it with a few "cut -d # -f #" but that could just be that I failed at awk.

Yes, I did use # as a comment in awk and a preprocessor line in C. I only had to use a few simple #define's take make my polyglot program work. Many other things have the same syntax in both languages, such as the control structures and printf(). Here's a basic C/awk program that shows how easily it can be done:
Code:


For practical use, awk is good for more than just splitting lines. I generally use sed instead for splitting lines. Here's the source code generator script that I mentioned:
Code:

It takes lines containing the system call number, name, number of argument words, and additional flags, and it outputs an expanded (non-sparse) C array containing the same information. For example, if you give it this input:
Code:

you'll get this output:
Code:

I used awk's associative arrays to do this. Its automatic line-reading loop, pattern matching, and word splitting help too. About one third of the script's lines are for printing source code or errors/warnings, so I'd be surprised if it could be made much shorter in another language like Python.

Python:


Code:


Shorter, sexier, cleaner, and just all around better.

More importantly, though, doing it in Python means you don't need to know awk.

Most importantly, my awk script works, and your Python script doesn't:
Code:

Yours doesn't check for and report lines with too few or too many fields, or error out if any index is duplicated, which mine does. I suspect that's why your script bombs on my real input file. It also doesn't add the index comments every 5 lines in the arrays, which admittedly is not really needed in generated output anyway. Both of these contribute to the line count of my script and would increase your script's size if you also included them. I also could've reduced the line count in my script by defining functions for repeated tasks like you did in yours, but it wasn't a high priority for me to reduce or minimize the line count in a script that's already pretty simple and short as it is.

Awk is old and showing its age somewhat, but it's still suited for tasks like this.

Eh, not a big fan of python simply because it's rather obsessive compulsive about formatting and "pythonic" code. It's a great language to read though

Fine, here (note, same line count :p)


Code:




Wasn't in the requirements (sounds like mine has an extra feature )

What actually happens with my program is last index wins, eg:


Code:


results in:


Code:




I only tested on the snippet you posted, and didn't spend all that much time on it - which is more likely why it bombs on your "real input"



I know, I thought it was stupid so I didn't do it. That's trivially added tbh.



Sure, but you're kind of missing the point. Once you actually have an awk script and not just something in line, you should switch to a better scripting language. Then you don't need to bother remembering all the magic awk variables and crap, and more people will be able to understand it and help. Moreover, the ability to add features increases greatly as you actually have a solid base to work from.



If you aren't already doing what python forces you to do, you are a terrible coder. No excuse for not indenting your code.

Nope, it's not an extra feature. I put it in my script since duplicate system call numbers is an error and should stop the 'make' command. I didn't list the full requirements (though I did list the source) because I wasn't expecting such fierce one-upmanship in this thread.



The only "magic" awk variables that I had to use are NR (number of records) and NF (number of fields), and those are used only for reporting error conditions (which yours doesn't even do). The BEGIN and END are analogous to main in C, being the entry points of the program. The variables $1, $2, etc, are like positional parameters in the shell. Nothing in the script is radically different from many other scripting languages, and it's quite easily understandable.

On the other hand, your script uses the "magic" Python variable "__name__", and it also uses Perl-esque "compound" statements (for lack of a better name) which reduces both line count and readability, maintainability, and all that good stuff.


More features? I don't need more features for this script. It does its job and doesn't need to do anything else (besides possibly add/removing fields as the system evolves). Do one thing and do it well, you know?

For some other tasks I might use Python or Bash or Perl or C, but like I said, this type of task is suitable for awk.

By the way, if I strip out comments and extra lines to match your script's style (but leaving in the warning/error messages, which I think is a good thing), mine comes out to 51 lines, only 4 lines longer than yours.

This is all becoming a pissing match, really.

Code:


That snippet right there proves you wrong. That's perl level ugly.



Purely for convention, it's entirely unnecessary.



I disagree. It's quite readable, very maintainable, and downright sexy. It does reduce line count.

Frankly I was actually having too much fun with those, which is why I kept using them.



A pissing match I'm winning, I'll point out. I didn't exactly strip mine down, either. I have unnecessary line breaks, the unnecessary __name__ == '__main__' convention, etc... Pretty sure I could make it smaller if you *really* want.

It's also off point. All you've proven is that someone actually has written an awk script, not that there is any REASON to write an awk script. Clearly it's no shorter, simpler, or readable.

Those are simple and succinct regular expressions, which predate Perl by many years. Any self-respecting programmer should be able to recognize and decode basic regular expressions like this one.

I actually could have left off the second regular expression because it never matches when the first one does, so it could've been shorter like this:
Code:

Easy!


Hahaha, ok. So you're winning a pissing match. What will be your next empty victory? Spitting the farthest?

You're only "winning" on the line count front. Readability and sexiness are more subjective. If I were trying to compete on line count alone, while not sacrificing readability, I'd also remove the warning/error messages in mine. That would bring it down to 38 lines, or 9 lines shorter than yours. If I also removed the hash-bang line (which isn't strictly necessary, but I would have to invoke the script with the awk command) and blank line below it, it would be 11 lines shorter than yours. But warning and error messages are a Good Thing™, and so is the hash-bang line, so I'm going to leave them in there.

Who says I don't? That doesn't mean I like being forced to do it.

STFU.