ryapric

While your recommendation is sound: this is not only a rudely-worded take, but also missing the point of the parent comment.

I enjoy it quite a lot :shrug:

Bash itself isn't a very big language, so I wouldn't call it "impossible to memorize".

Yep, you have it correct. I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. I said the same in another comment here, but I don't envision vdm becoming something that's git-specific or developmental -- it's really just intended to be a getter, not a writer, and the functionality reflects that.

Cool info though, thanks for sharing!

This tool looks like "submodules, but lighter", while repo is "submodules, but heavier". Looks to me like the motivation is for dependencies that are not hard enough to justify a submodule.

I think you nailed how I was feeling in much fewer words!

Sure, but not all my code in a single repo is monolingual code, and not all of those languages have cooperative (or existing) package managers. Bash is a great example of something I wish I could stop copy-pasting between repos, and was actually the original motivator for vdm (along with protobuf files, for the same reasons).

Thanks! That AOSP `repo` tool is one I'd not heard of, so thanks for sharing!

I actually haven't really put much thought into collaborative/mutlirepo development work using vdm -- the original intent was for it to strictly be a retriever of what the user specifies. I think the majority of both my frustration and complexity of other tools is because they're trying to solve for a lot more than at least I personally usually want to use them for. It's like, I just want a `pip install/requirements.txt/go.{mod,sum}` for any kind of tool, not just the language that takes up the majority of my codebase.

One of the thoughts I had, though, was to maybe add a field for each remote section called e.g. `try_local` that takes a filesystem path, and if that doesn't exist then fetch the remote. That way, your development workflow is exactly the same as usual -- developing a dependency is just doing work in the actual repo directory nearby. I'm not married to the idea though. I just REALLY don't want to have it be in the business of managing git-repos-in-git-repos, because vdm isn't really intended to be a Git tool, if that makes sense.

What I'm I missing?

The parent isn't talking about e.g. EC2 as a virtualized platform, they're talking about EC2 not being a virtualization platform. With few machine-type exceptions, EC2 doesn't support nested virtualization -- you can't run e.g. KVM on EC2.

I never said anything about one-liners?

On mobile so no idea if this a) looks good or b) runs (especially considering the command substitutions, but you could also redirect to temp files instead), but it's just something like this:

    N=0
    while read -r URL; do
      data="$(curl "$URL")" || { printf 'error fetching data\n' && exit 1 ; }
      prop="$(jq '.data[].someProp' <<< "$data" || { printf 'error parsing JSON response\n' && exit 1 ; }
      grep -v "filter" <<< "$prop" > "$N.data" || { printf 'error searching for filter text\n' && exit 1 ; }
      N="$((N+1))"
    done < ./links.txt

Edit: oh good, at least the formatting looks ok.

That's really not that hard to add above. A lot of folks act like it's impossible to handle errors etc. in bash, but it's pretty straightforward -- certainly no more difficult than in any other language. The hard part, like with all languages, is deciding how to handle errors cases. The rest is just code.

I think it's very much your last theory -- used everywhere but not as interesting to tell people about as it might have been a decade ago. Queues are now Boring Technology(tm), and that's a good thing.

Definitely just as useful even if it is!

Yikes.

I never really even entertained the idea of agreeing with this until just this week actually, when I was putting log statements into bash functions that were supposed to return strings -- and failed for reasons I could not understand. Six full hours of debugging later, I realized that the logs were writing to stdout, and thus were cluttering the expected return values.

I'm still not fully sold on the idea, but I now have at least one tangible example of when you would want to keep stdout clear of commentary.

Why would you want to use JavaScript in IoT scenarios?

I run Debinan Sid/Unstable, both as my home desktop (with XFCE as a DE) and as my headless WSLv2 OS on my work machine. I've had it on the desktop for something like, 4 years now? Before that, I ran Manjaro on the desktop since something like 2017, and Xubuntu on the work laptop (as its own partition).

I've only ever had one problem with Debian Sid, which was this year I believe when a `libssl` update broke a lot of things (git, ssh, etc). Other than that, anecdotal smooth sailing.

I believe they're talking about how abstractions tend to make people more productive. Operative term being "tend to", because I personally wouldn't use this tool either, but to each their own.

I wonder if they might be talking about `go vet`?

Click on the "All" toggle on the top of the page.

So post two openings to close the gap?

As the shebang (`#!`), I imagine you mean?

you get typechecking and all the rest of the editing experience

This is true for a number of languages that can also be run without AOT compilation (Go, Rust, etc). This feels like some really weird, incoherent astroturf take for Bun promotion.

Do you know of any browser games that use Ctrl as the crouch key? That's the interface under discussion.

Is this relevant to the post/discussion though?

I don't think you can capture/handle exit codes of subshells anyway, right? I've been operating under that assumption for years, and just don't do subshells if I can avoid them.

Weird that no one has yet to actually discuss `xonsh`, which the video is actually about.

However, I'm about to do the same lol, and come out as a bash apologist against the sea of derision here. I've spent a decade writing code in maybe 10 different languages, and bash is still what I write the most of -- and its by choice! If you're writing a lot of code that calls other code, bash is kind of the default choice, since that's literally what the shell is for.

Once you spend enough time with it, I actually find bash to be surprisingly elegant in what it affords the author in its terseness. Combined with other CLI utilities' own concision, it's an incredibly powerful environment. Sure it can start to appear arcane to unfamiliar folks, but you can work to make it significantly more readable than most people would have you believe. And with e.g. shellcheck, you can do away with a great deal of common footguns.

A comment above points out that it's a book originally written in Russian, so.

Yeah they probably should have linked Moonlight[1] in the README.

[1] https://moonlight-stream.org/

The same problems any imperative management within declarative config causes -- drift. If the tool you're using supports declarative configuration, all changes should be made exclusively via the declarative interface to prevent that drift. In this example, the new image should be added to the original manifest itself, not via a CLI update.

Did consulting work for a place that gave their execs bonuses based on story-point velocity... jesus.