More out of curiosity than anything else, what's the use case requiring this?

HAHA! I didn't see your post until after I posted - good opening line ;-)

This one does not work with l/python-requests-2.22.0-x86_64-2.txz which requires

I downgraded to python-idna-2.8 but there's also a git commit for python-requests that limits dependencies to major instead of minor:
https://github.com/psf/requests/comm...c64e2011f37361 (but I did not test that, so it might require more changes!)

2 members found this post helpful.

Understood. Thanks!

Mesa 20.0.0 is out.
ftp://ftp.freedesktop.org/pub/mesa/mesa-20.0.0.tar.xz
I had to comment out the old "0001-swr-Fix-GCC-4.9-checks.patch.gz" for it to configure.
Mesa 20 should be interesting for many users.

Is there a need for two strings commands? The more versatile /usr/bin/strings-GNU version is provided by the GNU binutils package. The other /usr/bin/strings-BSD version is provided by the util-linux package.

I suggest using a better maintained ksh derivative, the current ast upstream seems to have suffered a huge reactionary regression...

Please see:

https://github.com/att/ast/issues/1466
https://github.com/att/ast/issues/1464

I think mksh is a good alternative.

http://slackbuilds.org/repository/14.2/system/mksh/

1 members found this post helpful.

/usr/bin/strings-GNU is a symlink to /usr/bin/strings.
There is also strings-BSD from the util-linux package.

1 members found this post helpful.

Yes, you are correct. I need to stop looking at my 14.2 system when I write my posts! Even the change log reflects the corrections.

I'm going to my room now to think about what I did.

2 members found this post helpful.

The easiest one for me to think of is an XFS /home partition with an external journal. The XFS header specifies only internal/external journal, but not the device containing the external journal; that has to be specified explicitly on the mount command line, or in /etc/fstab.

(FWIW, an XFS root partition with an external journal requires a custom initrd. Putting "rootflags=logdev=" on the kernel command line doesn't work, or at least it didn't the last time I tried it 5 years ago.)

1 members found this post helpful.

Thanks for posting. As a long time fan of ksh, I have to say that was a really depressing read. Given the issues with 93v- I wonder if we'd be better going back to 93u+ in current once the dust settles and we know what is what.

The problem with the various clones is that they're ksh-like, but they're not a true ksh. Having said that, bash has stolen it's thunder at the low end, and python/perl supplanted it at the upper end, so maybe it's time has simply passed.

1 members found this post helpful.

Set the compression method and ratio for btrfs to reduce writes to ssd.

1 members found this post helpful.

There is ksh 2020 (situ.im) which may be something to keep an eye on. I tried it for a short period of time and it seemed OK and IIRC I did not see any regressions. But I would rather stick with what Slackware ships.

I use the 'real' ksh in scripts because I need compatibility with proprietary UN*Xs I use at work.

FWIW, RHEL 7.7 installed mksh on my workstation at work due to some package we are forced to use (my company only allows Windows or RHEL for desktops).

Edit:
I re-read the above link and I could not find the link to the repository, so I found this github and in spite of the banner, seems there were recent commits.

My impression is that ksh93u+ is an old and bit rotten mess which has long been abandoned by any developers that care about it. While the last two developers for the modern work on ksh93 have now given up and left the repo in charge of people not willing or capable of taking it any farther.

So for a working and maintained ksh shell I think that leaves mksh, loksh and oksh (The latter two are both similar openbsd ksh ports).

My take from reading those KSH issue threads is that, yes 93u+ is old and bit rotten, but it's the same old and bit rotten version that commercial unixes have been shipping for years. If you want compatibility then it's the version you want. The recent development has stemmed from the incomplete and buggy 93v- (beta) branch which AT&T didn't finish before sacking everyone involved and ceasing development on it. ksh2020 is a descendent of 93v- and while some of the issues from that release have been addressed it seems that many in the community still prefer 93u+ (which is why they rolled the repo master branch back).

Controversy seems to have kicked in because in addition to fixing the issues stemming from 93v- the developers have been changing behaviours of ksh rather than just maintaining/cleaning up the code and some parts of the ksh community really didn't like that aspect.

Now, I'm an outsider so my take is based entirely on what I've read in those issue threads and it's possible I misunderstood something, but I think that's the general gist of it. The whole thing is a mess and it's really sad to see.

looks like freebsd are going to stick with 93u+

1 members found this post helpful.