[HN Gopher] Aho - a Git implementation in Awk
___________________________________________________________________
Aho - a Git implementation in Awk
Author : pabs3
Score : 267 points
Date : 2024-02-10 16:05 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| artsi0m wrote:
| Might be relevant:
|
| sed-chess: https://news.ycombinator.com/item?id=37896854
|
| awk-raycaster: https://github.com/TheMozg/awk-raycaster
| erk__ wrote:
| There is also a Google (and more) translate client written in
| AWK
|
| https://github.com/soimort/translate-shell
| artsi0m wrote:
| I found an awesome-awk[1] page on github and is seems to be a
| little empty. Maybe we should contribute to it and bring some
| examples like subj of this HN post or ahrf[2], dedicated
| markup language for static site generators based on awk. I've
| started with adding one true awk and bioawk implementations.
|
| [1]: https://github.com/freznicek/awesome-awk [2]:
| https://github.com/Ypnose/ahrf
| bitwize wrote:
| At first I thought this was named for _aho_ (aho), Japanese slang
| for "stupid", then I remembered that Alfred Aho is the 'a' in
| 'awk'. Or maybe it's both?
| bangonkeyboard wrote:
| Both, I assume. "Git" was already slang for "stupid person," so
| this is a clever name.
| phkahler wrote:
| I always assumed git was a sort of slang for get. So you "git
| the code" or use git to get code.
| samatman wrote:
| The pun is there for sure, but "git" is British slang for
| an unpleasant or annoying person. I was introduced to it by
| The Beatles: "and curse Sir Walter Raleigh, he was such a
| stupid git".
|
| I believe it was Linus himself who quipped (paraphrasing)
| that he is so arrogant he named two software projects after
| himself: Linux, and git.
| CharlesW wrote:
| My most recent experience is hearing it in _Reservation Dogs_ :
| https://en.wiktionary.org/wiki/aho#Navajo
| ghc wrote:
| I bet it's both. Extremely clever wordplay!
| Towaway69 wrote:
| Great project and great idea. Understanding the basics gives one
| different perspectives for other projects and problems.
|
| Back in the day I created a Web-based wiki using awk. Why?
| Because I was using linksys router with minimal memory.
|
| It was a great learning both how wikis work and what can be done
| with awk. And since there are no libraries to fallback on, I had
| to implement the basics and gain all the understandings.
| snovymgodym wrote:
| Awk is cool. It's a full-fledged programming language that's
| there in anything remotely unix-flavored, but I mostly see it
| used in one-liners to grab bits of text from piped stdout.
|
| But you can use awk as a general-purpose scripting language [1],
| in many ways it's nicer than bash for this purpose. I wonder why
| you don't see more awk scripts in the wild. I suppose perl came
| along and tried to combine the good features of shell, awk, and
| sed into one language, and then people decided perl was bad and
| moved on from that.
|
| [1] Random excerpt from NetBSD's source code
| https://github.com/NetBSD/src/blob/trunk/sys/dev/eisa/devlis...
| smburdick wrote:
| Does that excerpt start with an if-else sequence?
| mksybr wrote:
| it starts with the BEGIN block
|
| https://www.gnu.org/software/gawk/manual/gawk.html#BEGIN_002.
| .. https://www.gnu.org/software/gawk/manual/gawk.html#Pattern
| -E...
| csdvrx wrote:
| > then people decided perl was bad and moved on from that.
|
| Screw what people think. I found out I like perl. The last
| thing I wrote is a programmatic partition editor [1] - like how
| you use sfdisk to zero out the partitions, except I wanted to
| do more than zap, like having the MBR and GPT partition table
| to combine them and make hybrids.
|
| I was fun, and I will use perl again (I may also use awk at one
| point now that I see how cool it is)
|
| [1] https://github.com/csdvrx/hdisk/
| blacklite wrote:
| Perl is a great programming language, unless true.
| Ultimatt wrote:
| Valid comment, unless $is_bad_example. I genuinely really
| like the use of unless in Perl. There are lots of times
| it's nicer to express inverse logic. You could change the
| name of a variable to have inverse truthyness and not have
| if not everywhere. Or you could accept you often need to
| deal with inverse logic on something and use the right
| language.
| dkarl wrote:
| You nailed it. Perl replaced awk and then turned out to be
| counterproductive in a lot of cases because there was no simple
| and broadly understood way for people to write Perl code that
| was 1) readable for other programmers and 2) scalable to
| medium-to-large programs.
|
| Which is not to say that nobody ever figured out those things
| and did them well, just that the success rate was low enough
| across the industry to earn Perl a really bad reputation.
|
| I'd like to see a revival of awk. It's less easy to scale up,
| so there's very little risk that starting a project with a
| little bit of awk results in the next person inheriting a
| multi-thousand line awk codebase. Instead, you get an early-ish
| rewrite into a more scalable and maintainable language.
| cmgbhm wrote:
| What Perl nailed was being useful to write cross platform
| shell scripts. Agree that it didn't scale up but you had a
| chance of delivering n platforms with minimal pain.
|
| awk v gawk doesn't make me want o to relive those days.
| kradroy wrote:
| > I'd like to see a revival of awk. It's less easy to scale
| up, so there's very little risk that starting a project with
| a little bit of awk results in the next person inheriting a
| multi-thousand line awk codebase. Instead, you get an early-
| ish rewrite into a more scalable and maintainable language.
|
| Taco Bell programming is the way to go.
|
| This is the thinking I use when putting together prototypes.
| You can do a lot with awk, sed, join, xargs, parallel (GNU),
| etc. But it's _really_ a lot of effort to abstract in a bash
| script, so the code is compact. I 've built many data
| engineering/ML systems with this technique. Those command
| line tools are SO WELL debugged and have reasonable error
| behavior that you don't have to worry about complexities of
| exception handling, etc.
| patmorgan23 wrote:
| May Introduce you to https://bashsta.cc/
| SOLAR_FIELDS wrote:
| The problem Perl and the like have to contend with is that
| they have to compete with Python. If a dependency needs to
| be installed to do something you have to convince me that
| whatever language and script is worthwhile to maintain over
| Python which is the next de jure thing people reach for
| after bash. The nice thing about awk is that it's baked in.
| So it has an advantage. You can convince me awk is better
| because I don't have to deal with dependency issues, but
| it's a harder sell for anything I have to install before I
| can use
|
| And it's not even that Python is a great language. Or has a
| great package manager or install situation. It doesn't have
| any of those things. It does, however, have the likelihood
| of the next monkey after me understanding it. Which is
| unfortunately more than can be said about Perl
| KerrAvon wrote:
| Bingo. I would argue Ruby has the quality of being a
| great language the next person can understand, but I
| think Rails has prejudiced people.
| Towaway69 wrote:
| Agree, Ruby is a wonderful language that is unfortunately
| dominated by an opinionated Web framework.
|
| Job descriptions tend to be looking for rails developers
| and forgetting that actually its Ruby developers they are
| looking for.
| GrumpySloth wrote:
| Perl is installed by default on most Unix systems.
| FreeBSD being the exception. Python isn't. Although
| Python is popular; if we're comparing the probability of
| someone having the interpreter installed already, it's
| greater for Perl, even if people aren't aware they
| already have it.
| SOLAR_FIELDS wrote:
| Though one would probably never be able to work with an
| assumed install of Python anyway because one would not be
| able to assume a specific version. I am guessing this is
| a lesser problem for Perl, since it's been frozen at some
| version of 5 for the past 25-30 years correct?
| neuromanser wrote:
| Incorrect. Perl (5.x) has seen 10 stable releases in as
| many years, IOW since 2014.
| dgfitz wrote:
| > Perl is installed by default on most Unix systems.
| FreeBSD being the exception. Python isn't.
|
| Most all "Linux" cannot even boot without python, and it
| is quite easy to find a minimal Linux distribution that
| does not have a dependency on Perl.
| GrumpySloth wrote:
| Care to give any examples of Linux distros without Perl?
| fourfun wrote:
| I've seen enough awk behemoths in my time, no thanks.
| cpeterso wrote:
| I'm curious: what are some problems where awk was
| (presumably) a reasonable choice at first but then the
| implementation grew into a behemoth? Did the solution need
| to grow as the problem grew? Or was awk just the wrong
| choice from the beginning?
| fourfun wrote:
| One case I saw it used was for processing genomics data.
| It was kinda ok at first but when we needed to add a new
| sequencing type it was laborious.
|
| Personally I don't think awk is a good choice for
| anything beyond one liners and personal scripts. Here it
| was fine because it was (initially) some write-once
| academic code that needed to not be insanely slow.
| anonnon wrote:
| > then people decided perl was bad and moved on from that.
|
| That's a large part of what's driving Awk's renaissance: devs
| that never learned Perl to begin with want something to fill
| the gap between shell and Python, and other devs like me who
| (reluctantly) abandoned Perl because it was deemed "uncool" by
| HN types, which means Perl and all code written in it now has
| an expiration date on it. But since Awk is a POSIX standard, HN
| types can't get rid of it.
| Almondsetat wrote:
| can't wait for the day I will be able to compile Linux
| without Perl
| fuzztester wrote:
| that's the day I'll eat my red hat
| LinuxProtips wrote:
| You can do that right now. Sabotage Linux rewrote the one
| and only perl dependency in awk years ago.
|
| Grab https://raw.githubusercontent.com/sabotage-
| linux/sabotage/ma... and clobber the perl script in the
| Linux source.
|
| Then: sed -i -e 's@perl
| $(srctree)/$(src)/build_OID_registry@awk -f
| $(srctree)/$(src)/build_OID_registry@' ./lib/Makefile
|
| They also removed the perl dependency for ca-certificates
| since one of the goals was to remove perl dependencies from
| the core system including its toolchain and kernel. It's
| not needed at all now.
|
| This Aho project is neat because it has the potential of
| removing the perl dependency on having a git client, which
| was a problem prior.
| bigstrat2003 wrote:
| "HN types" can't get rid of perl either. So just use perl if
| you want to. Personally I think perl is a terrible language
| and that anything which is too complex for a shell script
| (which is most things) should just be done in python. But if
| you disagree, it's not like anyone can stop you. If your
| issue is "my teammates hate it and want me to use something
| else", I promise you they will be just as annoyed if you use
| awk.
| lanstin wrote:
| I'm pretty sure people have read more perl code than awk
| code, so they'll roll their eyes but will be able to cover
| for perl-required tasks, but won't build up the courage to
| touch the awk.
|
| To me, hell is having to debug perl scripts other people
| wrote. Based on experiences in the 1998 time frame.
| dleink wrote:
| took a contract job where I was writing a thing in perl
| to connect a billion dollar collection of ecommerce sites
| to facebook ads in 2019.
| oooyay wrote:
| What is an "HN" type? HN has smart, dumb, and in-between
| people of every variety. That's the byproduct you get of
| encouraging curiosity. I don't think HN was even around in
| any sort of prominence when Perl died.
|
| I stopped using Perl because my egg drop bots got laborious
| along with my expect scripts. They were novel early on, but
| maintaining them became something of a chore I wasn't
| inclined to do anymore. Other things started to do that
| better.
|
| Personally, I think Python won because it's syntax was much
| more readable. It had nothing to do with technical merits. DX
| is a strong subliminal motivator.
| sgarland wrote:
| Awk is incredibly useful. I wrote a script this week to parse
| Postgres logs (many, many GB) to answer the question, "what
| were the top users making queries in the first few minutes at
| the top of every hour?" [0] Took a couple of functions, maybe
| 20 LOC in total, plus some pipes through sort and uniq [1].
| Also quite fast, especially if you prefix it with LC_ALL=C.
|
| [0]: If you're wondering why there wasn't adequate
| observability in place to not have to do this, you're not
| wrong, but sometimes you must live with the reality you have.
|
| [1]: Yes, I know gawk can do a unique sort while building the
| list. It was late into an incident and I was tired, and | sort
| | uniq -c | sort -rn is a lot easier to remember.
|
| [1].a: Yes, I know sort has a -u arg. It doesn't provide a
| count, and its unique function is also quite a bit slower than
| uniq's implementation.
| v3ss0n wrote:
| you can do that in a lot lesser line of code in python and
| much better performance.
| sgarland wrote:
| I suspect the performance part is only true if you're
| familiar with Python's stdlib performance quirks, like how
| `datetime.fromisoformat()` is orders of magnitude faster
| than `datetime.strptime()` (which would likely be the
| function you'd reach for if not familiar), or at the very
| least, that directly casting slices of the string into ints
| is in between the two. This example is parsing a file of
| 10,000,000 ISO8601 datetimes, then counting those between
| `HH:00:SS - HH:02:SS` inclusive. The count method is the
| same, and likely benefitting some OS caching, but the parse
| times remained constant even with repeated runs.
| $ python3 times_python.py strptime_listcomp parse
| time: 45.96 seconds count time: 0.54 seconds
| count: 498621 $ python3 times_python.py slices
| parse time: 9.96 seconds count time: 0.40 seconds
| count: 498621 $ python3 times_python.py isofmt
| parse time: 0.80 seconds count time: 0.38 seconds
| count: 498621
| bagful wrote:
| I love AWK. Its stringly-typedness would make a Javascript
| programmer blush: 0, "", and actually-nothing are identically
| falsey. Numbers are no different from strings representing
| numbers, like Lua. Somehow, I don't mind -- if you really need
| to keep your numbers numbers and strings strings, sigilate the
| value (prepend with #/$) and peel it off with a substr() later.
| garaetjjte wrote:
| Lua does not represent numbers with strings. It does have
| number type which is always floating-point.
| nmz wrote:
| Integers were introduced in 5.3.
| samatman wrote:
| I like the way Lua handles strings and numbers quite a bit.
| They're different types, but arithmetic will convert a string
| to a number when it can.
|
| This is without footguns, because concatenation is a
| different operator entirely. 2 + "3" -- 5
| 2 .. "3" -- "23"
|
| It's rather convenient, especially when you can combine it
| with LPeg to parse files with numbers in them, then do the
| maths directly.
| v3ss0n wrote:
| awk isn't readable. modern programming languages can do things
| much better than awk in much lesser lines of code.all of them
| have better code to work with text and string.
| GrumpySloth wrote:
| _> much lesser lines of code_
|
| Doubtful. awk has a lot of implicit behaviour which allows
| the programmer to write very terse scripts. An equivalent
| Python program is usually several times longer.
| csydas wrote:
| > awk isn't readable.
|
| I mean, russian is also unreadable, until you know how to
| read it.
|
| awk's power for me isn't the LOC needed to accomplish a task,
| its power is that I can express the business logic I need
| very easily and very quickly, and the resulting code is
| really fast. I am by no means great with awk, but I can go
| months without touching awk, encounter some problem where awk
| shines, and in a few minutes or less I have exactly what I
| need.
|
| you can learn to be extremely productive with awk in a few
| hours and it's very comforting to have this in your toolset
| moving forward. Essential? Probably not, but I like that I
| don't need to break my thought process when working with awk
| because it's just so natural to express what I want awk to do
| that I don't really "think" about writing awk, I just write
| it.
| srean wrote:
| Disagree on both counts.
|
| For the problem domain that Awk targets, its close to as good
| as it gets. Lot of the line reading, delimiting, chunking etc
| is already done for you. You the programmer dont have to deal
| with re-implementing that same old ceremony. You get straight
| to the point of writing the transformations that you want.
|
| If you break out into Python for that, that's a bit like
| being at your best and formal self, your best table manners,
| the first time you are meeting your fiance's parents. Awk on
| the other hand is like being with you old childhood pal,
| partner in crime, from your old street where the need for
| such ceremonies do not exist.
|
| With modern awks you can write extensions for them. Mawk is
| plenty fast too.
|
| One thing that still grates though is that the 'split'
| function does not come with a corresponding 'join' and one
| has to iterate through the array explicitly to join.
| heresie-dabord wrote:
| > people decided perl was bad
|
| Like any programming language, you have to get good at Perl to
| write good Perl.
|
| Python has clean notation. It's a juggernaut that has changed
| people's expectations of language design.
|
| But even so, Python has not decreased the amount of bad code in
| the world. Not even within Pypi.
| abhgh wrote:
| I have written scripts in awk (what seems a lifetime ago!),
| bash, then perl, ruby and python - in that chronological order.
| I think awk scripting didn't take off for the masses because
| while it was good for its goal, (1) it was a bit niche; the
| common knowledge people came in to work on unix systems was
| bash and awk/grep/sed one-liners - learning awk would have been
| work that was seen to have specialized gains, (2) yes, Perl
| sort of provided a sane alternative to the mix of shell
| scripts, magic one-liners and awk scripts. Of course, later it
| was supplanted by Python (transitioning through a brief period
| of Ruby).
|
| Reading legacy scripts was wild back then - you had to be
| somewhat good at bash, unix tools like awk, C, make, Perl:-)
| sampo wrote:
| > I don't plan to add network functionality to this (even though
| you totally can), so no _clone_ or _push_.
|
| You can also git clone from a repository in a different directory
| in the same computer. And push to.
| d-lisp wrote:
| Exactly, but having branches kind of allow you to not have to
| create local clones. And I legit use rsync to clone locally git
| repos. The question is : what is the best ?
| nerdponx wrote:
| You can have multiple worktrees per repo. Usually that's the
| best solution instead of local clones.
| kilroy123 wrote:
| This is what I do for complex projects.
| d-lisp wrote:
| That's interesting, some kind of meta branches.
| kazinator wrote:
| The git-worktree man page says: BUGS
| Multiple checkout in general is still experimental, and
| the support for submodules is incomplete. It is NOT
| recommended to make multiple checkouts of a superproject.
|
| Source: https://git-scm.com/docs/git-worktree
|
| It complicates git with more cruft. A separate clone is
| more understandable and independent. If you trash something
| in its .git/ subdirectory, only that repo is affected.
| more-coffee wrote:
| That is so obvious.. yet I've never thought to try this in 10
| years of using git.
| amelius wrote:
| Does it solve the large-file bottleneck? Then I might use it for
| my deep learning models.
| supriyo-biswas wrote:
| It doesn't, since Git's data model has to be changed to
| content-defined chunks to solve the issue.
|
| You should look at git-lfs[1] instead.
|
| [1] https://git-lfs.com
| amelius wrote:
| I've tried it but it doesn't play nice with git-shell, and
| thus for me is too much of a hassle to set up.
|
| Also, I'm not a huge fan of tools that implement important
| functionality as an afterthought, especially if those tools
| deal with my precious data.
| aseipp wrote:
| No, Git's object store was not designed to hold large binary
| blobs, and no implementation of Git in any language can change
| this. It's a reasonable request; I mean, Git doesn't even deal
| with "pretty small" binary files very well, either. But it's
| all simply a consequence of its design that was thought up all
| those years ago.
|
| The core object storage model and data format (and many, many
| things on top of those) have to be changed/extended/fixed
| first, but it's realistically an immense change, so git-lfs and
| other various solutions are about as good as it'll get in the
| mean time.
| sodapopcan wrote:
| Not the most interesting of questions I have here, but is this
| indentation style on function definitions a thing or is it just
| accidental? It's in a few places, mostly before the first arg but
| sometimes before others.
|
| eg: function run_command( c, shortopts,
| longopts, quiet, directory, path, errors)
|
| Just asking as this project has kind of resparked my interest in
| awk.
| michaelcampbell wrote:
| I noticed this too and can't figure it out. Spaces between SOME
| parameters, not all, and not consistently placed
| rbonvall wrote:
| Awk doesn't have a way to define function-local variables. All
| variables are global, except for function parameters.
|
| This spacing convention is meant to clearly separate mandatory
| parameters and optional parameters that are sometimes only
| introduced to "declare" a local variable.
| bewuethr wrote:
| Here's where the manual introduces the convention: https://ww
| w.gnu.org/software/gawk/manual/gawk.html#Variable-...
| sodapopcan wrote:
| Oh cool, thank you!!
| michaelcampbell wrote:
| Thanks; this may be one of the most weird conventions I've
| ever come across. Maybe that's a 'me' thing.
| throw0101b wrote:
| The book _The AWK Programming Language, Second Edition_ was
| released this past September (2023):
|
| * https://awk.dev
|
| The first edition was published in 1988, and is available at:
|
| * https://archive.org/details/pdfy-MgN0H1joIoDVoIC7
|
| * Discussion: https://news.ycombinator.com/item?id=13451454
| smburdick wrote:
| Alongside Brian Kernighan, the "K" in K&R C, and much more Unix
| lore.
| adonovan wrote:
| This 35-year gap is a great story to tell your editor whenever
| they ask "so how's that second edition coming along...?"
| kazinator wrote:
| The original authors have done next to nothing to improve Awk
| in those years; it's embarrassing to be writing another book
| on a subject that they have not advanced.
|
| Awk could use improvement in numerous areas. Oh, for
| instance, you can pass associative arrays into functions, but
| not return them. Functions that filter array to array have to
| take an output array parameter.
|
| Using extra parameters as the only way to get local variables
| is also a smell.
|
| a[i] syntax cannot index into strings, what the hell?
| chris_wot wrote:
| Just for contex, Aho is 82, Weinberger is 81 and Kerrighan
| is dead.
| ksherlock wrote:
| Brian Kernighan is alive.
| layer8 wrote:
| And 82, just to complete the data.
| banku_brougham wrote:
| I just wanna say i have love for the while crew and
| jumped when i saw that about BK. thanks for posting fast
| chris_wot wrote:
| I apologise for my error! And I am very happy he is
| alive.
| usr1106 wrote:
| He gave a keynote at what I believe was the last
| Linuxconf Australia. Maybe 2 years ago or already 3?
|
| Of course he could have died since, but as others noted,
| he hasn't.
| ksherlock wrote:
| CVS support (--csv) was added last year (to the one true
| awk and gnu awk)
| EasyMark wrote:
| GRRM should probably use that as something to refer to as
| people pointing to him completing "the damn book"
| dang wrote:
| Related:
|
| _A Git Implementation in Awk_ -
| https://news.ycombinator.com/item?id=28771841 - Oct 2021 (96
| comments)
| forrestthewoods wrote:
| Neat project. It's always fun to see tools pushed beyond their
| normal use cases.
|
| That said, it should be a criminal offense to write any tool this
| large and complex in any language that can't be used in a
| powerful step debugger.
|
| TBH I'm increasingly frustrated by the amount of code written in
| Bash. I kind of hate Python for various reasons. But if 100% of
| Bash was replaced with Python I think the world would be a better
| place.
| riddley wrote:
| I'm mostly in concordance, but one thing I think every
| scripting language got wrong is how painful it is to run
| external binaries. Sure it can be done but it could be as easy
| as a shell script.
| forrestthewoods wrote:
| Agreed.
|
| That said, stdout/stderr is such a bloody, inconsistent
| nightmare. I'm not totally convinced that "chain small binary
| programs together" is better than "one language with useful
| libraries".
|
| Bash is admittedly nice for small things. But it always
| spirals out of control. And rarely gets ported.
|
| Also my life is primarily Windows and if you want everything
| to "just work" across mac/linux/win it's easier to just use
| Python or sometimes even Rust. I often wish I could easily
| write and run single-file rust scripts.
| wazbug wrote:
| Ruby is nice in this regard though :-) x =
| `git --version` puts(x) #=> "git version 2.43.0"
| KerrAvon wrote:
| Ruby is really nice in this regard, in fact -- you're not
| limited to backticks; you can use any quote delimiters you
| want.
| riddley wrote:
| Ruby is nice in every regard :) Most languages have some
| form of backticks to run an external binary. When I left my
| original comment I got a phone call in the middle of it and
| rushed it, sorry about that. What I really meant was having
| the versatility of the big 3 file descriptors along with
| return codes, etc. You can use Open3 (in the ruby case) but
| it's unwieldy compared to, say bash.
| Brian_K_White wrote:
| Only if python gained the ability to execute externals and
| handle stdin/stdout/stderr, return value, & environment
| directly instead of through exec(). And ditched the meaningful
| indentation. And was backwards compatible so that old scripts
| work today and today scripts work tomorrow.
|
| Bash has it's own uglies so I guess it's fair enough to compare
| two imperfect things, but the problem is these are two
| different jobs, and python just doesn't do the job bash does,
| and that job needs doing, so python can't be the replacement.
| Keyframe wrote:
| There's this lingering thought in my head that with a bunch of
| GNU utils/programs and probably not much more one could create
| these omnipotent databases and processing tools that would
| surpass in performance and capabilities tools specialized in it.
| Anyone else feels like that?
| zilti wrote:
| Oh yes, and a project like this exists/existed:
| https://en.wikipedia.org/wiki/Strozzi_NoSQL?wprov=sfla1
| Keyframe wrote:
| Fantastic, first time I hear about it. So there's _something_
| to it, alright.
| Qem wrote:
| https://adamdrake.com/command-line-tools-can-be-235x-faster-...
| kazinator wrote:
| If this used cppawk (which didn't exist when this was developed),
| it could use #include. This is nicely relative to the file; no
| AWKPATH. Also you can just "build" the preprocessed program into
| a single file which then doesn't need cppawk.
|
| https://www.kylheku.com/cgit/cppawk/about/
| xonix wrote:
| You can also implement includes in couple (tens) of lines of
| AWK: https://maximullaris.com/revamp_define.html#mglwnafh
| freedomben wrote:
| When people ask me why I say that the linux command line is the
| best dev environment, Awk is one of the tools I often point to.
| When you know even basic awk, you can do a lot with a little.
| IDEs actually start to feel clunky.
|
| If you're looking to get into Awk, and you learn well from a
| lecture style, I put together a talk for Linux Fest Northwest
| some years ago and recorded it for Youtube:
| https://youtu.be/E5aQxIdjT0M
| corytheboyd wrote:
| How does awk replace an IDE? I love awk, I love how powerful it
| is if you spend the time to learn it, but if I didn't have an
| IDE I would be significantly less productive. Most of what an
| IDE does is help you understand and change code, not text
| editing operations. Not trying to say you're wrong, just
| curious what your angle is with that statement.
| freedomben wrote:
| Thanks, to clarify, I don't mean that just awk replaces an
| IDE. I mean that the Linux command line replaces an IDE,
| specifically the functions like finding references,
| substitutions, transformations, etc. It doesn't replace
| syntax highlighting and stuff of course, though I get that
| from Vim.
|
| It's never going to be as powerful as a specialized IDE would
| for a specific language, but the Linux CLI is language
| agnostic and even works on just text files, so it's
| universally applicable and doesn't change depending on the
| language of the project. For me it's better than an IDE, but
| YMMV of course because everybody is different.
| brabel wrote:
| I don't understand why you're associating AWK with Linux in
| particular... it seems it's available on Windows, BSD,
| MacOS and probably more.
| freedomben wrote:
| Ok yes, point taken, I just meant it as a general
| expression. I don't mean to imply that it's exclusive to
| Linux, although I do specifically prefer the GNU flavor
| of most of the tools (awk an exception where there are
| multiple interesting implementations), which do tend to
| be more closely associated with Linux than macos or BSD.
| A standard installation of any Linux distro will have
| them all available, whereas in Mac and Windows you have
| to specifically install them as they aren't part of the
| standard command line.
| brabel wrote:
| MacOS comes with AWK and most other utilities... with a
| few just having different names. IMHO it's basically as
| extensive as GNU/Linux.
| freedomben wrote:
| Macos does not come with the GNU utilities. You have to
| explicitly install them if you want them on macos. The
| included versions are BSD and similar licensed and are
| not all compatible with the GNU versions.
| makeitdouble wrote:
| At the same time unicode support was added super late (like 2
| years ago ?), like any other shell tools passing content to awk
| by piping has edge cases (anything ressembling a CTRL+D
| sequence will cut the feed, and there must be dozens of other
| edge cases I have no idea about that will only bite me at the
| worst time.
|
| Awk is an impressive tool, but putting it on a pedastal blinds
| people from the weak spots and why they should probably move
| serious tasks to more specialized, but modern and adapted
| tools.
| themk wrote:
| You have to be trying pretty hard to make a CTRL-D cut the
| feed when piping into shell tools.
|
| That only comes into effect when the input is coming from a
| pty, and that only when it's in a very specific mode that is
| meant for interactive use.
| kazinator wrote:
| When you see code like: function
| read_objfile(obj, objpath, bytes, end_of_header, header,
| end_of_type, type, size,
| bytes_after_header)
|
| the parameters separated by the big white space are local
| variables. It's possible to pass them values, but you're not
| supposed to.
|
| I wrote a patch for GNU Awk to give it a let statement for
| binding true lexical variables, so that this could be:
| function read_objfile(obj, objpath) { @let (bytes,
| end_of_header, header, end_of_type, type, size,
| bytes_after_header) { } }
|
| Unfortunately, this was rejected by the project; I was encouraged
| to make a renamed fork of GNU Awk, so that's what I did.
|
| https://www.kylheku.com/cgit/egawk/about/
| coliveira wrote:
| I feel they have a point, gawk has already too many differences
| compared to awk. If you introduce even more distinct syntax, it
| is better just to fork it and call it something else.
| earthboundkid wrote:
| The perfect project name doesn't exi...
| runiq wrote:
| Yeah, digging the name. For the uninitiated: 'aho' is basically
| 'git' in Osakan.
| EasyMark wrote:
| can be built as a part of busybox too, which I've found useful a
| few times on embedded linux systems with limited
| resources/program space
| hajimuz wrote:
| Aho means dumb ass in Japanese. Haha
| chanux wrote:
| In Sinhala it's Alas!
| Towaway69 wrote:
| What's wrong with hello in pirate speak? ;)
|
| https://en.m.wikipedia.org/wiki/Ahoy_(greeting)
| kinow wrote:
| I thought the same think. And it is super common in manga and
| anime, so a lot of people know wordslike aho, baka, kuso to
| have a bad meaning in japanese.
| srean wrote:
| Thats how you address your significant other in Marathi, so
| that 'dumbass' maybe all in affection.
| pyuser583 wrote:
| Dear lord, why?
| v3ss0n wrote:
| if you are using awk for more than 5 lines of code just use
| python.it is painfully slow and unreadable, there is no benefit
| of using it at all. if you are saying awk is fast you yad never
| benchmarked it against other programming languages. even pyhon is
| 10-20x faster.
| dexzod wrote:
| I don't understand how you can write more that one line long
| program in a language where all variables are global by default
| even if they are inside a scope delimited by brackets. You can
| have local variables but the syntax is weird.
| https://www.gnu.org/software/gawk/manual/html_node/Variable-...
___________________________________________________________________
(page generated 2024-02-11 23:01 UTC)