I think there's an argument to be made that this is the terminal emulator at fault for assuming it's being fed UTF-8 when it's not (Elvis is just feeding out a bunch of bytes as far as its concerned). But terminal emulators have been screwy for a long time as experienced any time you cat a binary file. Unfortunately, pointing fingers doesn't really help in this situation.

No there isn't. The terminal emulator is innocent here. elvis' lack of utf8 support is the issue. If elvis were a GUI application it would still have the same problem.

But lets not get this thread any further off-topic by arguing it in here.

1 members found this post helpful.

No, in a GUI application, a single UTF-8 accented character would be presented as 2 or more odd looking characters. Cursor positioning would be safe, you could add and remove ASCII characters before and after the accented characters without corrupting the file. The same applies to Elvis/xterm, but NOT Elvis/urxvt. Elvis/urxvt represents the UTF-8 characters correctly, but misses the cursor positioning, which makes it dangerous. If you delete a character, it looks right, until you reopen the file.

Again, back to the topic please.

ImageMagick 7.0.9-17
https://imagemagick.org/download/Ima....0.9-17.tar.lz
https://imagemagick.org/script/changelog.php
Bison 3.5.1
https://ftp.gnu.org/gnu/bison/bison-3.5.1.tar.xz
https://ftp.gnu.org/gnu/bison/bison-3.5.1.tar.xz.sig

Alpine 2.22
http://alpine.x10host.com/alpine/release/
http://alpine.x10host.com/alpine/rel...ne-2.22.tar.xz

1 members found this post helpful.

rEFInd finished building from get go. Both packages where present at one time (old was named all lower case).

I find it a bit odd to not have all the binaries in /sbin or /usr/sbin (a hard Slackware requirement?) but i managed to find them by less-ing the package in /var/log/packages.

Short of the packaging oddities I see no reason to not include?

Once endorsed those can easily be "ironed out" I guess...

Make 4.3
Source: https://ftp.gnu.org/gnu/make/make-4.3.tar.lz

Yes, those binaries could be soft link to /usr/sbin

https://github.com/troglobit/sysklogd

https://packages.gentoo.org/packages/app-admin/sysklogd
https://crux.nu/gitweb/?p=ports/core...b7c62fdb912f90

I'd asked about GPU computing setup on freenode IRC ##slackware, so one thing I'd love to see on next Slackware is Radeon Open Compute (ROCm.) However these AMD drivers have such large codebase (and maybe between 100 and 150 dependencies) it may depend more on what OSes its team port to, than what OSes want to add ROCm... in relation to similar classic Unix[-like] OSes, it could take so many years/decades to audit every line of code I'm not sure OpenBSD Unix would ever have ROCm (because of security focus)... it seems FreeBSD Unix at least added newer Radeon drivers, if not also working on ROCm. I don't know if Pat or Slackware team must audit every code line or trust AMD's Free/Libre/Opensource Software (FLOSS) intentions and code. ROCm has been asked to port to FreeBSD and if they do, it's not far-fetched ROCm team should port to truly Unix-like (i.e., non-systemd) GNU/Linux. As for Nvidia, they're still secretive, so I may not care less whether Slackware gets CUDA... my opinion is the same as Linus.

Lately just to run AMDGPU-PRO (until ROCm becomes more stable or straightforward setup) I've had to have been using a systemd OS () on desktop and Slackware on laptop (and on main servers, or OpenBSD) but for me a real OS is more important on desktop. If ROCm doesn't come to Slackware and/or FreeBSD I'll just have to stop using ROCm unless I get space for a secondary computer running ROCm.

I'm impressed by features of QubesOS GNU/Linux (I'd like to see available on non-systemd OSes such as Slackware and *BSD) not for security paranoia, but for usability/productivity... because of how it uses Xen, you can run multiple OSes within Qubes then run programs from those OSes in the same GUI as if all part of it. It'd be interesting to see forks/combinations of Qubes software and Slackware (of course, without systemd, and re-enabling host OS networking) to let you run programs from other OSes without inset in an emulator/virtual-machine window (so you needn't key in & out.) Of course, that's probably too big a project unless someone more knowledgeable than me maybe just makes that a Slackware fork... probably not something almost any OS team would want to take loads more time adding as an option, even if might make them more popular than the rest (when you can run the rest inside it.)

Another thing (if I haven't mentioned)... I'm not sure this is a feature of an actual Unix terminal, or certain shells, but it'd be excellent to have the option on Slackware to page up in shell history same way as in *BSD Unix... that is, you needn't hold down <SHIFT> for all <PAGE UP>--maybe with two hands--you just press <SCROLL LOCK> to start, <PAGE UP>, maybe sip a cup of tea/coffee with your other hand while still paging up, then exit with <SCROLL LOCK>. Maybe that's only a ksh thing, and Slackware has ksh available... but after eventually using bash more than I'd used ksh for years, ksh also has some inadequacies (can't source an rc file, can't use <BACKSPACE> on typical ksh OS, like NetBSD Unix, without special setup)... so I don't know what would be best...

1 members found this post helpful.

Slackware64-current fully upgraded (repositories slackware, multilib, alien) today and very annoying php_errors.log every half hour:

Can you please comment that and how to get rid of it as php is compiled without wddx.

just comment the line
in /etc/php.ini then restart httpd or php-fpm (depending on what you are using).

2 members found this post helpful.

krb5 \o/

2 members found this post helpful.

That's not really a request now, but a statement ;-)

3 members found this post helpful.

yep, more of a "thanks a lot!"

3 members found this post helpful.