

I think this is relevant: https://news.cs.washington.edu/2013/08/14/chicken-chicken-chicken-chicken-chicken/
I think this is relevant: https://news.cs.washington.edu/2013/08/14/chicken-chicken-chicken-chicken-chicken/
I can imagine that someone would find a program like this to be useful, and depends on the presently common behavior of zcat
, so I expect this is an important part of a system used by a corporation I interact with (and probably many more than I’d expect):
if
zcat ./file.txt.gz >/dev/null
then
process_file ./file.txt.gz
else
printf '%s\n' "There was a decimal exit status of ${?}"
fi
A failure to understand whether something is useful is not a good reason to change it.
Whatever the first implementation does ends up being a suicide pact by default.
I agree. The behavior of rm
and cat
and cp
and mv
and dd
and many other utilities don’t necessarily have the interface I would prefer, but they are too widely used for it to be helpful to radically change them. It’s somewhat unfortunate that these names are already reserved, but I don’t think it’s necessary to change them.
In the same way, I don’t have a problem with packages having generic names but not actually being useful: I’ve read that the requests
and urllib3
packages for Python aren’t being maintained very well, but I don’t mind that as long as I can accomplish things while following best practices.
Because of this, I’m not afraid to use names like “getRequest” or “result”, especially if they were generated with an automatic refactoring, and I’m not upset when I see similarly generic names being used with source code I’m changing, since I know that the second name for something that’s similar to an existing thing will have to actually be descriptive, but the first name is likely to not be.
I have another example of how I’d apply these thoughts: the process for developing v2+ modules for the Go programming language strikes me as inelegant, so I would probably prefer to just create an entirely new repository rather than try to attempt that.
What operating system should I use with my laptop that isn’t an awkward kludgy idiosyncratic mess? I would say that Windows has plenty of kludges, like having problems with certain file names. Many versions of macOS are UNIX® Certified Products (for example, macOS version 15.0 Sequoia on Intel-based Mac computers and on Apple silicon-based Mac computers), so it’s surely not any less kludgy than Linux.
I suppose that it’s not bad to change documentation to be more specific, and change a program such that it matches the new documentation and wouldn’t cause any harm if it replaced all the existing versions of the program, but makes it possible to use the program to solve more problems. That would be to “add functionality in a backward compatible manner”.
You are also free to create new programs that are not an exact replacement for existing programs, but can enable some people to stop using one or more other programs. That would not be what I describe as stagnation.
“The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence.”, so I would be very annoyed if it did something different with a certain file but not others. I wouldn’t say that the contents of a file and the contents after the file is expanded are the same.
In fact, I expect that some people use cat
to process compressed files, and changing how cat
acts with compressed files would probably cause them a large amount of annoyance, and would needlessly make a lot of existing documentation incorrect.
I think that providing an exit status that is not 0 when zcat
is used with an uncompressed file is useful. Though my opinion is less strong regarding whether it should write more text after an error occurred, it’s probably more useful for a process to terminate quickly when an error occurred rather than risk a second error occurring and making troubleshooting harder.
I think that trying to change any existing documented features of widely used utilities will lead to us having less useful software in the future (our time is probably better spent making new programs and new documentation): https://www.jwz.org/doc/worse-is-better.html https://en.wikipedia.org/wiki/Worse_is_better
You are correct. This probably produces something more similar to what you’d want the original command to do, but with better safely:
find -- . -type f -regex '^\./[^/]*$' -exec sh -c -- 'for file in "${@}"; do zcat "${file}" || cat "${file}" || exit; done' sh '{}' '+'
That assumes you want to interact with files with names like .hidden.txt.gz
though. If you don’t, and only intend to have a directory with regular files (as opposed to directories or symbolic links or other types of file), using this is much simpler and even safer, and avoids using files in a surprising order:
for i in *; do zcat -- "$i" || cat -- "$i" || exit; done
Of course, the real solution is to avoid using the Shell Command Language at all, and to carefully adapt any program to your particular problem as needed: https://sipb.mit.edu/doc/safe-shell/
Remember that the system documentation can be different for different operating systems. For example, it’s notorious that the documentation for sed
differs between GNU and macOS, particularly regarding the -i
option: https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux
In order to avoid surprises related to this, “POSIX.1-2024 defines a standard operating system interface and environment, including a command interpreter (or “shell”), and common utility programs to support applications portability at the source code level.” https://pubs.opengroup.org/onlinepubs/9799919799/ https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
Technical problems and political problems can be related, and discussing one in the context of the other can be useful.
“10,000-Year Earworm to Discourage Settlement Near Nuclear Waste Repositories (Don’t Change Color, Kitty)” https://en.wikipedia.org/wiki/Ray_cat#Cultural_impact https://emperorx.bandcamp.com/album/10000-year-earworm-to-discourage-settlement-near-nuclear-waste-repositories
I definitely recognized “Huskvarna” for some reason, but didn’t know its location or why I would have recognized it before reading your comment. I haven’t lived in Sweden or a place that would have been very easy for me to get to Sweden from.
Typo: s/FOUR\/FOR\/s/s\/FOUR\/FOR\//
To “substitute”, the editing command is s/RE/replacement/
which has a s
character before any <slash>
(/
) character: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html#tag_20_109_13_03
Did something supercede Socialism in Russia around the years 1988 to 1991?
This might be relevant:
https://youtu.be/J_fZ9o6P0-A?si=-fl7rLryYZBDVgTN&t=194
Conditions here were deplorable by any objective measure. And if you’ll recall, one of the hallmarks of early Russian industrialization was: the workforce was often transient. People moved back and forth between their home villages and jobs in the cities, and this flux meant that the places people lived and where they ate and bathed and got medical attention were only ever temporary expedients. It was a bit like you were going off to some particularly crappy summer camp. It was only meant to be temporarily endured, not lived in full time, and so conditions just never got better. People were not just renting rooms; they were renting corners of rooms. You could rent not just a bed, but part of a bed. Sanitation was, of course, practically non-existent, and the food was disgusting. The work itself, meanwhile, was long and grueling. There were no safety standards in the factories. There were hardly any rights for anybody at all. And pay was literally inadequate. The ministry of finance itself surveyed conditions and concluded that a family of four needed about fifty rubles a month to purchase basic necessities (that is, food and shelter and heat) and then they found that 75% of the workers were making less than 30 rubles a month. The economic and moral math was just not adding up.
https://youtu.be/J_fZ9o6P0-A?si=FtaiY47HVyXXBeAP&t=340
The lower skilled, less educated, and still mentally “peasant” workers tended to remain culturally conservative. They were orthodox christian and believed strongly in the divine benevolence of the czar. And indeed one of the things reported by both social democrats and SRs back to their respective central committees was that they struggled to recruit among these workers because they were out there pitching “overthrowing the czar” and everyone was like “What? We… we love the czar, and he loves us too!”
To them, the czar was not a villain, but a hero. Not the devil, but their savior. It understandably made recruiting for a political revolution to overthrow their “hero and savior” very difficult.
https://thehistoryofrome.typepad.com/revolutions_podcast/2020/02/1033-bloody-sunday.html
Note that many versions of macOS adhere to these standards: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/brand3700.htm https://www.opengroup.org/openbrand/register/brand3705.htm
If people were more resistant to “grandfathered” features I think we would not have as much software as we do today: https://www.jwz.org/doc/worse-is-better.html https://en.wikipedia.org/wiki/Worse_is_better
provide about 50%–80% of what you want from an operating system
one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere.
Unix and C are the ultimate computer viruses.
users have already been conditioned to accept worse than the right thing.
It’s probably possible to make several programs with “50% functionality” in the time it takes to make one program with 100% functionality. Having more programs that are suitable for a majority of relevant applications is probably better than having one program that is suitable for all relevant applications, since having more programs will probably enable a larger variety of problems to be solved, and people often have to solve many different types of problems in their life.
https://refspecs.linuxfoundation.org/fhs.shtml https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html
Some operating systems may handle long path or file names in a surprising way, so having short paths and names is useful: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
If any pathname component is longer than {NAME_MAX}, the implementation shall consider this an error.
if the combined length exceeds {PATH_MAX}, and the implementation considers this to be an error, pathname resolution shall fail
{NAME_MAX}
and {PATH_MAX}
are described in more detail at https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_02 and used in the context of https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pathchk.html
The resources I linked are descriptive and not prescriptive, but in my experience they are suitable to depend upon as a reliable baseline, which makes meeting client requirements with software engineering easier.
My response to the body of this post is https://www.privacyguides.org/en/real-time-communication/
This might address the URL of this post (I’ve never interacted with “iCloud” so I don’t necessarily know what would be a good replacement for it): https://www.privacyguides.org/en/document-collaboration/