Timeline for How to print all key-value pairs of certain sections in an INI file?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 5, 2024 at 9:23 | comment | added | Gao | @EdMorton You are correct, it is the old awk (and the old grep without support for the -E option) in /usr/bin! I'm honestly quite surprised since /usr/bin/sh in Solaris 11 is ksh93, but they haven't upgraded the other utilities. I guess I have to alter the PATH at the beginning of my script. | |
| Nov 20, 2024 at 11:40 | comment | added | Ed Morton | I haven't had access to a Solaris machine for years so I can't test it but I haven't heard of any change to the default awk and I'd be surprised if they changed it since doing so would cause a lot of existing scripts that rely on old awks "functionality" to break. If you do have access to a Solaris 11 machine you could try running some of the scripts from awk.freeshell.org/oawk and then let us know if /usr/bin/awk is still old awk or not. | |
| Nov 20, 2024 at 11:35 | comment | added | Gao | @EdMorton Didn't Solaris 11 get a big overhaul? That was true for Solaris 10 and older, which I am not supporting. Is it still the same in Solaris 11? | |
| Nov 20, 2024 at 11:19 | comment | added | Ed Morton | @Gao I see you mentioned Solaris in a comment. Just be aware that the default awk on Solaris in /usr/bin is old, broken awk (see awk.freeshell.org/oawk) so don't use that version - use one of the other awk versions that come with Solaris, i.e. nawk and, preferably, /usr/xpg[46]/bin/awk. | |
| Nov 18, 2024 at 13:22 | comment | added | Marcus Müller | what that is worth in practice, where tools then violate POSIX? IMHO, not that much, but your opinion seems to differ on that, and we shouldn't be arguing about opinions! My main point was that "long-term stable" is less valuable than "can definitely deal with all input that you'll present it with, and easy to fix in the future". | |
| Nov 18, 2024 at 13:09 | comment | added | Gao | At least with POSIX we have some vague rules to point at which when violated we can blame the implementations for introducing "bugs", and also because currently my script does not have a dependency on Python (well, not even awk except this part). I'm not ruling out Python as an option yet, but I'm going to see what other solutions are available. | |
| Nov 18, 2024 at 13:00 | comment | added | Gao | @MarcusMüller Python 3.13 removed 19 modules from the standard library (some of the removed modules, e.g. telnetlib, has been around since at least Python 2.0, released in 2000). Also, I recall Python has a release policy of only giving deprecation notice 2 minor releases beforehand and could be removed after that. Compare that to Java, where the only real change is Java 9+, and only some people are affected by it. | |
| Nov 18, 2024 at 12:54 | comment | added | Marcus Müller | @grawity note that this is the output, not the input of the awk script, in Gao's question. But you're right, if that's the quoting in the input file that we see in the output, we have a problem with tomllib, but not with configparser. A simple substitution in the script above, though! | |
| Nov 18, 2024 at 12:51 | comment | added | Marcus Müller | becomes unavailable. | |
| Nov 18, 2024 at 12:51 | comment | added | Marcus Müller | have some contingency plan for when something minor needs to be adapted to a newer version of the awk implementation a target system runs. Frankly, a well-readable awk script is easy to maintain in the future, so not that bad a choice! But: if the alternative is 9 lines of Python that actually parses an ini file, instead of doing a fragile approximation of it, then that's the better choice, as in the end, you want robustness not long-lived, fragile software: it's IMHO more likely that some unforeseen variation of the input data breaks your "would-be" parser than that a real parser | |
| Nov 18, 2024 at 12:46 | comment | added | Marcus Müller | "Python has very bad backward compatibility, so configparser or tomllib I use today might be removed later. I want stability" Um, yeah, that is counterfactual. configparser has been around for 20 years. Whatever you do, it's not going to be as stable as core libraries in Python3, promise. You're aspiring highly, and that's honorable, but thinking your config file parser needs to outlive Python longetivity borders on hybris, maybe :) But anyways: don't ignore that pretty "standard" tools like make, sed etc do break occasionally, too. Either you pin your software versions, or you need to | |
| Nov 18, 2024 at 12:44 | comment | added | Marcus Müller | @Gao A software being old is no guarantee for it being used everywhere. Ada is a lot older than Java, but how many smart phone apps do you think are written in Ada? So, that's not really an argument. Same for ed vs Visual Studio Code, ksh vs bash or zsh, and so on. | |
| Nov 18, 2024 at 12:34 | comment | added | grawity | The format in OP's example is definitely not TOML. It is vaguely similar to TOML, in that TOML was inspired by it, but it does not follow the TOML syntax and indeed tomllib raises a syntax error at the 2nd line (due to string values not being quoted, something that INI and TOML formats have the opposite rule on). Python's ConfigParser would be a more likely module. | |
| Nov 18, 2024 at 12:34 | comment | added | Gao | I won't count on python3 the name being always available without manually symlinking or installing some stub packages, and Python has very bad backward compatibility, so configparser or tomllib I use today might be removed later. I want stability. | |
| Nov 18, 2024 at 12:28 | comment | added | Gao | How is it possible that you have met more systems without awk than Python? Awk is several decades older and tens of megabytes smaller than Python with as many if not more implementations. Is it one of those avant-garde operating systems like Manjaro Linux that makes questionable choices such as not including vi/vim by default? | |
| Nov 18, 2024 at 12:24 | comment | added | Marcus Müller | re: Python version: the Py2/3 thing is done, it works as python3 everywhere I tried. If you need only "oldskool ini files" (from your original description I was assuming you didn't, not all classical ini parsers deal with space characters in sections, and you used one), then import configparser is your friend | |
| Nov 18, 2024 at 12:20 | comment | added | Marcus Müller | I assure you that I've met more systems without awk than python, but that's anecdotal evidence only. I don't think something as "most" BusyBox installations is something one can define; most busybox systems are deeply embedded computers (fridges, routers, car dashboards) or smart phones, so I don't know whether it's worth thinking about what they might need, unless you are specifically targetting a specific device with busybox built in a way that enables the awk applet. | |
| Nov 18, 2024 at 12:15 | comment | added | Gao | tomllib is only included in the standard library since Python 3.11, and I'm wary of using Python because of the Python 2/3 divide and naming mess (python, python2, python3). It also might not be as ubiquitous as awk (is it available in most BusyBox installations?) and I don't want to ask users to install anything, so it should be a utility that is preinstalled on most Linux and BSDs, macOS, and Solaris 11. I'm content with an approximate solution that doesn't understand the whole INI format. | |
| Nov 18, 2024 at 12:11 | history | edited | Marcus Müller | CC BY-SA 4.0 | added 146 characters in body |
| Nov 18, 2024 at 12:05 | history | edited | Marcus Müller | CC BY-SA 4.0 | added 8 characters in body |
| Nov 18, 2024 at 11:59 | history | answered | Marcus Müller | CC BY-SA 4.0 |