Hacker News: marklgr

New comment by marklgr in "Show HN: Linux CLI tool to provide mutex locks for long running bash ops"

marklgr — Thu, 17 Jul 2025 12:45:32 +0000

Could you elaborate?

New comment by marklgr in "Show HN: Speech Meter – Improve Your English Pronunciation"

marklgr — Wed, 11 Oct 2023 17:32:51 +0000

I've been using the Boldvoice app (no affiliation), it's not perfect but pretty good; my spoken English has definitely improved in a few months. I would recommend it.

New comment by marklgr in "Magnetism may have given life its molecular asymmetry"

marklgr — Sun, 10 Sep 2023 19:46:29 +0000

Can't be natural selection, can it? Sheer luck?

New comment by marklgr in "uBlock Origin 1.50.0"

marklgr — Wed, 07 Jun 2023 16:12:59 +0000

If someone finds a way, I'm in.

New comment by marklgr in "Shells are two things"

marklgr — Thu, 09 Feb 2023 09:21:34 +0000

FWIW, if you just like the filename on the left, you still can save forks with:

New comment by marklgr in "What I'd like to see in Emacs"

marklgr — Wed, 07 Dec 2022 08:26:31 +0000

> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface.

It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons.

Anyway, it is not directly related to your point, but I think that example is not that compelling.

New comment by marklgr in "A Vim Guide for Advanced Users"

marklgr — Thu, 01 Dec 2022 10:59:15 +0000

Reading the docs and searching into it on a regular basis is the single best advice I could give to Vim users wanting to improve. The odd cheatsheet, the post with a few tricks and cool plugins, all those can be well and good, but nothing beats sitting down and reading the docs. I've been use Vim daily for 10+ years, and I still check help files very regularly. Knowing _how_ to search efficiently is also a skill worth acquiring.

Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.

New comment by marklgr in "Shell script best practices, from a decade of scripting things"

marklgr — Thu, 27 Oct 2022 12:14:02 +0000

> "If you have to write more than 10 lines, then use a real language"

I swear, there should be a HN rule against those. It pollutes every single Shell discussions, bringing nothing to them and making it hard for others do discuss the real topic.

New comment by marklgr in "Shell script best practices, from a decade of scripting things"

marklgr — Thu, 27 Oct 2022 12:05:02 +0000

It's a case of knowing the wooledge website (and working with shellcheck), or not. Picking snippets on stackoverflow will probably do more harm than good, tbh.

New comment by marklgr in "HP Saturn"

marklgr — Thu, 22 Sep 2022 14:29:43 +0000

I still remember 3223 :)

New comment by marklgr in "HP Saturn"

marklgr — Thu, 22 Sep 2022 12:10:03 +0000

Did you hang out at Maubert Electronics? I also recall a few RTC servers, blast from the past!

New comment by marklgr in "Pure Bash Bible – A collection of pure bash alternatives to external processes"

marklgr — Thu, 17 Feb 2022 09:36:10 +0000

Yes, it can be cryptic and not beginner-friendly, but it's powerful and once you know it, you know it; it will be useful for years if not decades, as opposed to some tools or frameworks du jour that are sometimes as cryptic.

The main issue is that many people try (by necessity or not) to cobble scripts together without really learning the language and its idioms. It's not that hard to really learn it though, it's basically one man page then the mandatory [wooledge wiki][1].

[1]: http://mywiki.wooledge.org/BashGuide

New comment by marklgr in "The Awk state machine parser pattern (2018)"

marklgr — Mon, 31 Jan 2022 10:35:28 +0000

Good book, for all levels, I recall stealing several snippets into my cheatsheet.

New comment by marklgr in "You shouldn't parse the output of ls(1)"

marklgr — Fri, 31 Dec 2021 15:50:40 +0000

String bets not allowed, whatever their encoding ;)

New comment by marklgr in "Unix Shell Programming: The Next 50 Years"

marklgr — Sun, 19 Dec 2021 12:20:51 +0000

Not OP, but I would say that we, regular Bash users, don't really write complex programs in Bash, even though it depends on what you call "complex". Some of our programs can be pretty long, and we can do more within Bash than some programmers know (eg. the arrays/associative arrays features, the vast parameter expansion options etc.), so no, we aren't bound to some 100-line-max rule, if that's what you had in mind.

Bash (and other shells) are very good at working with other programs and using the filesystem. It's true you have to know many idioms, but once you're there, you can be quite productive for these kinds of tasks.

New comment by marklgr in "Why, oh why, do those nutheads use vi? (2007)"

marklgr — Tue, 07 Dec 2021 08:01:16 +0000

Multiple-cursor editing is a nice and cool feature, and for what it's worth there are some vim plugins to get it in vim, but let's see the alternative:

- multiple-cursor: select non-contiguous pieces of text, then edit them all at once.

- vim macro/repeat: edit a piece of text, and repeat on similar occurrences.

The vim "way" could be, `/;$` to select the trailing semi-colon, then `cgn` to edit it (enter the curly block once in insert mode, then exit with ``), and now you can repeat on the next trailing semi-colon simply by hitting `.` (dot).

So, instead of first looping on the occurrences to get multiple cursors, then do the editing, you first do the editing on an occurrence, and you loop on the editing. There is admittedly less of a "wow" factor, but I don't think it is any less powerful.

(edited for formatting).

New comment by marklgr in "Why, oh why, do those nutheads use vi? (2007)"

marklgr — Tue, 07 Dec 2021 07:42:15 +0000

I also like and use tools like sed and awk; using the vim internal tools are very easy to learn if you come from there, and they have the advantage of being better suited for working with whole buffer (multilines, paragraphs etc.), instead of on a line-by-line basis.

I believe vim is a great editor for the kind of people who like sed, awk, and working from/with the shell, since it's pretty much the same culture.

New comment by marklgr in "Why, oh why, do those nutheads use vi? (2007)"

marklgr — Tue, 07 Dec 2021 07:33:15 +0000

Yes, if you want/need an IDE, by all means do. Vim is an editor, a very powerful one with all sorts of tools, but it's generally ill-advised to try and make it work like an IDE.

As far as I'm concerned, as a grey beard sysadmin, I don't need an IDE, so I value more the advanced editing features of Vim and I've been happy with it for years (more than I'd like to admit).

New comment by marklgr in "Senate leadership pushing a surveillance bill as Americans focused on Covid-19"

marklgr — Tue, 17 Mar 2020 20:31:26 +0000

Churchill, IIRC.

New comment by marklgr in "My FOSS Story"

marklgr — Mon, 20 Jan 2020 08:05:50 +0000

Slightly tangential, but that former stance you describe partly is a consequence of the age-old dualism between emotions and reason, to which people quite frequently subscribe despite strong evidence in the last decades from neurosciences that this is just not an adequete model--that's not how our mind work. We are not some sort of judge in their cartesian theater deliberating between the good, rational-mind and the lively but childish emotional-mind.