What scripting languages come out of the box on Debian 12?

https://hiandrewquinn.github.io/til-site/posts/what-programming-languages-come-out-of-the-box-on-debian-12/

by hiAndrewQuinn • 2 years ago

67 80 2 years ago

hiandrewquinn.github.io

z3t4• 2 years ago

What about compilers? What is an OS without a compiler?

ziotom78• 2 years ago

It's called “Windows”

flohofwoe2• 2 years ago

macOS and Linux too though? As far as I'm aware, most Linux distros need the build-esssentials (or equivalent) package installed, and on macOS the Apple Clang toolchain also isn't pre-installed. Both is quite similar to installing the "MSVC Build Tools" (MSVC command line toolchain without the Visual Studio IDE).

hnlmorg5• 2 years ago

Compilers are generally separate packages rather than part of the base install.

pjmlp5• 2 years ago

An opportunity to make money, commercial UNIXes eventually started selling their compilers as well, a practice started by Sun.

supriyo-biswas4• 2 years ago

Knowing that a language is installed by default on the most popular Linux distribution can simplify certain concerns considerably

The author laments the decline of such knowledge, but the proliferation of containers, combined with the marketing efforts of the large cloud providers has reduced the number of people who work with servers directly.

I should say that this knowledge can be useful in certain niche situations, though. For example, I recently learned that GitHub Actions pulls in a basic set of utilities by using complicated distro detection[1], and Gitlab runners similarly pulls in a Docker image with git just to clone a repository!

Instead, the proper way to address this situation would be to compile static binaries, that, by their very nature, become distribution agnostic. The only reason I assume this wasn't pursued, I assume, would be that the developers working on this weren't even aware this was an option.

It's the reason I've been maintaining a small set of packages[2] that I mount into every CI container for my personal projects. I'm also quite hopeful about the cosmopolitan project[3] that builds fat binaries which can bridge this gap, although as I discovered, some containers even lack tools like gzip (which cosmopolitan depends on), so maybe static binaries it is.

[1] https://www.youtube.com/watch?v=9qljpi5jiMQ

[2] https://github.com/supriyo-biswas/static-builds

[3] https://github.com/jart/cosmopolitan/

hnlmorg5• 2 years ago

Instead, the proper way to address this situation would be to compile static binaries, that, by their very nature, become distribution agnostic.

Thats only true if you do not depend on glibc, which some statically compiled binaries still do. And even then, you’d have to rule out anything that requires newer sysalls or platforms that don’t offer stable ABI guarantees (Linux is actually the edge case here in that most kernels offer no guarantees).

It’s certainly doable though.

arccy• 2 years ago

it's not really static if you depend on glibc... things can still break, e.g. when compiled on too new glibc it fails to run on older versions.

supriyo-biswas4• 2 years ago

The glibc dependency can usually be eliminated through the same process of static compilation; the binaries I linked are also built this way with no dependencies on glibc, for example.

platforms that don’t offer stable ABI guarantees

If we're talking about Windows, the Win32 ABI is considered stable, which would also suffice for what I'm looking for, which are portable binaries that can be run on almost any version of a system.

tripflag• 2 years ago

Replacing glibc with musl is usually unproblematic. That's what I did for my own portable toolbox which builds to a single self-extracting binary; https://github.com/9001/lxc

pjmlp5• 2 years ago

Instead, the proper way to address this situation would be to compile static binaries, that, by their very nature, become distribution agnostic. The only reason I assume this wasn't pursued, I assume, would be that the developers working on this weren't even aware this was an option.

Nowadays you even have younger developers praising static linking, as if this wasn't what we had around since the invention of the first linker, and dynamic linking only became mainstream in the 1990's.

Naturally only knowing Linux, GCC and glibc doesn't help.

almostgotcaught• 2 years ago

Nowadays you even have younger developers praising static linking, as if this wasn't what we had around since the invention of the first linker, and dynamic linking only became mainstream in the 1990's. Naturally only knowing Linux, GCC and glibc doesn't help.

It's amazing how low-brow condescension passes for wisdom. Let me give you a hint: ontogeny does not actually recapitulate phylogeny. So just because you have some vague memories of previous iterations of a technology does not mean that it's the same thing being discussed today

alexey-salmin2• 2 years ago

I'm not too young and I saw various methods of deploying code in production: deb packages, tarballs, docker images, static binaires.

I have to say that in my experience for a specific use case of a highload c++ daemon, nothing beats the simplicity and reliability of the static binary with musl. You only want to deploy one thing, you have nothing to share, furthermore you wouldn't want to share anything for the sake of control. So many things to worry about and to waste time on just disappear. When things are on fire having less variables to check is gold.

otabdeveloper44• 2 years ago

Containers fix nothing, because inside your container is still a Linux distribution. (Often it's just Ubuntu, because why not.)

the proper way to address this situation would be to compile static binaries

Nix is the proper way to address this. We'll get there eventually anyways, might as well bite the bullet now.

supriyo-biswas4• 2 years ago

I don't think Nix solves this use case, the linked binaries would still have dependencies stored at /nix/store/... and is hardly a solution for obtaining binaries that work anywhere.

zvr• 2 years ago

This is perfectly OK for your own work, but if you want to distribute stuff to others, statically linking increases your workload a lot. Because you are essentially distributing an increased number of components and your obligations increase multi-fold.

regularfry• 2 years ago

A reminder that interpreters installed with the OS are for the OS, not for you.

Plan on installing your own so that you can control versions, libraries, and packages.

(Yes, this post is about "in extremis" dev where you may not be able to do this. Still.)

rini172• 2 years ago

Nonsense. Bash is for the OS not for you too?

Python's standard library covers most scripting use cases, even HTTP networkingand it's stable you can write script and forget. No need to "control" stuff. For example I am using minimal python script + cron for updating letsencrypt certificates in misc linux distros. Everywhere it's system python out of the box without any additional dependencies or virtualenvs.

xarope• 2 years ago

That's why I learned REXX in ye-olde days, because it came installed as default on IBM systems (and not Perl, which was my de-facto prior to). Then python. Nowadays Go(lang).

Still trying to decide if it's worth going to Rust for script'ish type work, I have a feeling it's not quite the right choice.

p_l• 2 years ago

Python versioning is BS enough and with enough systems problematic enough that for scripts that have to assume widest range? I torture them with POSIX sh.

flohofwoe2• 2 years ago

At least on macOS, Apple strongly discourages depending on the builtin scripting languages, and AFAIK python is no longer preinstalled (instead installing Xcode for the first time will slip a python3.9.x and pip3 into your /usr/bin).

Of course you can depend on zsh/bash, but then the Apple UNIX tools are BSD flavoured, not GNU flavoured like on Linux, so Linux shell scripts will also quite often not work out of the box on macOS.

globular-toast3• 2 years ago

Yes and no. In a way a system interpreter is just like a compiler. It's there to enable the user to run programs written in a particular language.

The trouble usually starts when a program needs some third party library. So maybe the rule is more like: the system libraries are for the system, not for you. Unless, of course, they are -dev libraries. I do believe modern Ubuntu won't even let users pip install stuff, which should improve things (Gentoo has been configured like this for years).

guappa2• 2 years ago

Well you can easily install python3-whatever and use it in a script on debian. What's the problem?

pip works fine if used in a venv. They finally blocked installing stuff system wide because it was creating mess.

https://xkcd.com/1987/

hnlmorg5• 2 years ago

Would ‘bc’ also count? You can do scripting in it albeit more for mathematical functions.

I can’t recall if it’s part of Debian base though.

hiAndrewQuinn3• 2 years ago

I totally forgot about `bc`! That should certainly count, I remember it having way more under the hood than a "mere" calculator program normally would.

fanf22• 2 years ago

How about ex? (headless vi)

enriquto• 2 years ago

5. sed, if you count that (I do)

If they count sed, they should definitely count vimscript !

pjmlp5• 2 years ago

This is the reason why I mastered enough vi to be dangerous, back in the day, Emacs / XEmacs were usually an additional package, while any sort of commercial UNIX had vi on its default install.

Being sent down into the field, rescuing whatever random server used by a customer, meant being able to use whatever was there, and between ed and vi, better vi.

m1keil3• 2 years ago

I don’t know why I don’t hear this point get more airtime among people when discussing the pros and cons of Python/Perl as scripting languages.

But it is.

Perl and awk one liners are very common. Bash is used everywhere you have the (controversial) `sudo curl .. | bash -` install method.

Ansible, if I'm not mistaken, requires python3 installed on remote hosts.

If your environments are homogeneous enough, and you don't have a large matrix of operating systems, you should definitely use this advantage.

The troubles start when you have very heterogeneous environment, custom or hardened Linux distros and etc.

It might seem like this is not being utilised as much nowadays, but I suspect it's because the "classical" Linux sysadmin roles are rare and you don't hear about it as much.

hiAndrewQuinn3• 2 years ago

Having recently started to experiment a lot with the BSDs (mostly Free, a little Open), which often don't come with even Bash out of the box (usually still Perl though), I can definitely relate to this. The more complex your workplace's OS ecosystem, the harder it gets to write anything which will truly run everywhere, unless you go all the way down to POSIX shell.

m1keil3• 2 years ago

Yep.

I assume everyone already knows that, but shellcheck is great help if you need to go all the way down to POSIX since it will detect /bin/sh shebang and warn about any non-compatible bash-ism.

em500• 2 years ago

Where does the expectation come from that Bash should come ootb with BSD? Or anywhere else outside of mainstream Linux distributions with GNU userland? Bash is the standard Bourne/Korn-like shell for the GNU project, which was envisioned as a FSF Unix clone/replacement. BSD and other Unix-like systems pretty much always had their own separate userland, with often different syntax than the GNU tools.

I think the odd one out was really Apple, which ran Bash as the standard shell for many years (a choice they probably regret), while most the rest of the userland was largely from BSD.

bionsystem• 2 years ago

Have you tried cfengine ? I'd be curious of the feedback in heterogeneous environments.

kodama-lens• 2 years ago

Ansible, if I'm not mistaken, requires python3 installed on remote hosts.

It is not a requirement. There is the raw module that just sends commands over ssh . But if you want to do anything beyond basic most people use raw just to install python so they can use other modules which require python.

m1keil3• 2 years ago

makes sense, thanks for the correction.

counterpartyrsk• 2 years ago

Perl 5? What version? Perl has been on that major version for some 20+ years, right?!

Calzifer2• 2 years ago

And will likely remain with that major version for the next 20 years since Perl 6 became Raku.

https://en.wikipedia.org/wiki/Raku_(programming_language)

maleldil2• 2 years ago

There will be a Perl 7[1], essentially Perl 5.32 with a new name.

[1] https://www.perl.com/article/announcing-perl-7/

alganet• 2 years ago

More interestingly, it would be nice to see their reverse dependencies:

    $ apt-cache rdepends --installed sed
    sed
    Reverse Depends:
      xml-core
      fuse3

Anyway, sh, awk and sed are there because it is mandatory: https://en.wikipedia.org/wiki/List_of_POSIX_commands

Perl and Python seems to support a lot of OS userland.

If you have GNOME, you probably have the gjs command too. It's a JavaScript interpreter.

contrarian12342• 2 years ago

When did Python join the list?

I remember I used to use Debian instead of Ubuntu b/c a minimal install didn't include Python

dugite-code• 2 years ago

According to this it's been shipped buy default for at least 11 years now: https://unix.stackexchange.com/questions/24802/on-which-unix...

contrarian12342• 2 years ago

That's probably only true on a full install. Something like Gnome or KDE will obviously drag in Python. But a minimal install with something like fluxbox would not

gorgoiler• 2 years ago

Curiously, I get why Go doesnt include the source code in its binaries — presumably a hangover from the long standing tradition of source for me but not for thee, as well as sever constraints on resources meaning source-included would be a frivolity — but are there compiled languages where it is an option to include the source?

The only one I can think of is TypeScript where it builds source maps to help debug the underlying JavaScript without having to see it.

usrusr• 2 years ago

Had the same thought recently. But it would be easy enough to make a "go script" frontend that checks for a compiled version, checks the source against a hash stored with that compiled version and shortcuts to the binary if everything matches, (re)creating it if not.

forrestthewoods3• 2 years ago

My opinion is that source code should be packaged up with debug symbols. I'm also a fan of breaking out debug symbols from the exe although that's a separate topic.

hiAndrewQuinn3• 2 years ago

(This page will briefly be down, as I add my new X profile at https://x.com/hiAndrewQuinn to its frontpage. Give it maybe 2-3 minutes from the time of this comment. God bless Hugo for being so fast to recompile. EDIT: Nevermind it was more like 30 seconds!)

globular-toast3• 2 years ago

Unfortunately the Python 3 debacle kind of ruined standalone Python scripts. At least for a while. Have distros gone back to having "/usr/bin/python" available (as opposed to "python3" or something else)? I bet there's still loads of system in the wild without a "/usr/bin/python", though.

Calzifer2• 2 years ago

Have distros gone back to having "/usr/bin/python" available (as opposed to "python3" or something else)?

Debian provides two packages python-is-python3 and python-is-python2 to restore the /usr/bin/python.

maleldil2• 2 years ago

Scripts should be using `/usr/bin/env python3` anyway, so they work inside virtualenvs and other scenarios where `/usr/bin/python` isn't the Python you want.

yjftsjthsd-h• 2 years ago

What's wrong with explicitly using "python3"? I guess maybe in theory you could maybe write a script that was compatible with both 2 and 3 but that sounds needlessly masochistic, and if there were ever going to be a python4 you wouldn't want to accidentally switch to it automatically either.

toolslive• 2 years ago

m4?

nbabitskiy• 2 years ago

Я 333

What scripting languages come out of the box on Debian 12?

Related Stories