Home | News | Download | Packages | Forum | Wiki | Github

Your WTFs and frustrations in Void

(Mitchell) #239

Not sure if this is the right spot for it or not haha,

Anyway I’ve installed Void Linux on 5 different computers now over the past month. And on all of them at various times certian packages have broken on update and a force reinstall fixes them, packages include


I’m assuming it’s just an install script or so not being re-run on on update?

  1. After the installation and selection zsh as user shell some (possible all) my shell-scripts (weather, for polybar, etc.) stopped normal working. Worked only if run bash and run script from it. Change of sha-bang (#!/bin/bash, #!/usr/bin/bash, #!/usr/bin/env bash instead #!/bin/sh) in scripts has no affected.
    Switching sh from dash to bash in xbps-alternatives helped, only now xbps-src started issuing warnings that bash is bad, switch back to dash. :smile:
  2. Env xterm-256color not [correct] work? In my previous Linux has always used it, but here I encountered an incorrect mouse operation in the MC when setting any variable for x-terminals, except rxvt-unicode-256color - only with it normal mouse behavior.


use chsh to change the shell, not xbps-alternatives


You do not understand - these are different things - the user’s shell and the system-wide shell (symlink /bin/sh).

(Masato the Empty) #243

My understanding of things is don’t do that. bash and dash will handle some things differently (behaviors that POSIX has left undefined where running it in bash will yield different results, though I have to admit, I think it would be more problematic to run bash-type scripts in dash as many things simply wouldn’t work…)

As far as the source of your problem… it doesn’t really make sense. UNLESS (and I just tested this) your scripts are not being invoked as executable files but instead as arguments to another shell command.

It’s the difference between a #!/bin/sh script.sh being invoked as

  • ./script.sh
  • zsh ./script.sh

The latter invokation has zsh interpreting the script (and the shebang is nothing more than a comment, as opposed to the magic number it would indicate in the former invokation).

Is that what’s happening on your system? dunno…


Thanks, in this way it works with dash: https://i.imgur.com/nHIsclw.png
But I still do not know whether to switch to dash or not? :grinning:


If I understand correctly, leave dash as the system alternative.

One way the things you are describing could be happening is that the initial script calls other scripts by invoking /bin/sh scriptname.sh, so the problem would not be immediately obvious and you would need to dig a bit further.

Also, calling by $(command) would depend on the environment, so if you didn’t fully logout-login after changing the shell, who knows what environment it would execute it in.

(Masato the Empty) #246

I found your cat ... grep sequence to be unusual and it inspired me (don’t ask me how, it’s just how my mind works sometimes) to check something.

It has to do with what the shebang is: a magic number representing an interpreter directive in Unix. This will happen if #! are not the first bytes of the executable file (0x23 0x21). I think even a BOM (which I believe shouldn’t be in Unix text files) can screw that up, and maybe that’s what’s happening in your case, or you could even have an empty line before the shebang…

try checking with head weather.sh or even by hexdumping the first line.

EDIT - to be clear: if the shebang is not the first two bytes of the file, the line will not be interpreted and the script will be run by your system’s default shell.


@masato you’re right.

@addhaloka didn’t you notice the WARNING in the INSTALL.msg ?

(maxice8's favorite salad) #248

bash is the systemd of shells, if you depend on bashisms just use #!/usr/bin/env bash


The warning is actually obsolete, it was for an update a long time ago but we switched to link libreadline statically so this won’t happen again.
You can use bash as /bin/sh, its just slower.


With this, everything is correct.

So wrote the “only now xbps-src started issuing warnings that bash is bad, switch back to dash.” :smile:

Its not works - above already wrote about this.

Still, if anyone does not understand:
If user’s shell - bash (as default) and system /bin/sh > dash, then the scripts work normally. But change bash to zsh - scripts not working, if /bin/sh > dash.
Probably have to use scripts so: zsh script. Other variant I do not know, if only continue use /bin/sh > bash. :grin:


The obsolete message has been removed: 76c0d42 :tada:

(Shane Kimble) #252

I used Void for about six months. As much as I wanted to keep using Void as my main distro, I can’t.

My frustration is that not enough ‘important’ xbps packages are archived long enough, in stable form, to easily roll back to without introducing instability. Not sure if a more Debian-like Void version is possible, but I’d be very interested in one :smiley:. I love runit and xbps, but Void is too Arch-like in it’s ‘bleeding-edgeness’.

I realized this when reverting to freetype-2.8. This is not a problem for most people, but I work for a data science company using Visual Studio Code as my primary tool. I have read all the threads in this forum regarding the issue, particularly those in the Discord crowd. When retrieving the specific commit from the master branch that included the specific freetype version from the tree, and compiling it using xbps-src, my system became highly unstable after downgrading to this version. Harfbuzz and X no longer wanted to play nicely. Yes, I could ditch the M$ tool but I’m adamant in my choice and have tried every other Python data science tool. Atom also suffers from the Freetype bug.

In the end, I just want things to work after I leave my system alone, and hope Void can also fulfill this mission one day. In the near future, I would be glad to help out the project however I can.


I secound this one.
the things I use nowdays mostly work still, but I get more nervus every time i do a -Suy.
for example, I used to be found of programing, made this filemanager once. It worked pretty fine, untill one day I made a upgrade, and sudenly gcc wanted me to make estetic changes to my source code., wierd segmentation faults, and the process i used to have to rewind the head in github stoped working… I dont program anymore, since it feels like the learning process is a wast of time if the continue to change how things work all the time… (gcc is changing really fast nowdays, was it just one year ago, they where working on version 5.x still, and now, all of a suden they’re alredy working on 8.0)

the horror of running in to a new systemd in this speed, really hunts my dreams.
Void is a little too good of a distro for that to happen to it.

so I would also sign up to help such a project if there ever would be one.
(I would devote my sundays to this, instead of going to chursh)

(maxice8's favorite salad) #254

yes but it is undesirable as not following upstream versions without extremely good reason is harmful and wasteful.


Well, a rolling release distro will most likely get the latest packages. Unless you manually make it block some.

A source based distro will take a long time to compile. But you get to customize.

A stable distro will have stale packages. Make sure they got a security team backporting patches.

You pick what you need, not the exact opposite, so then you can say you don’t like it.

Devuan has a stable branch. Ubuntu used to also support upstart instead of systemd. They got LTS.

And gcc update breaking code is not distro related, more code related.


if the gcc version 6 breaks the code and version 5 dont, then it is the choise of versions fault, hens the distro (if it offers nothing else)

I find it wastful to just throw away all those nice old abandon programs that people have made… and i find it more harmfull when things dont work at all.

Im not shure at all, in what it is you find so harmfull actully, to not rush in to every new version out there?
nor this conversation, (I have seen you bash on every one who complains about too instable versions),
wouldn’t it be better if all we, who want’s this more stable aprotch, got together and maybe tryed to do something about it?, whitout people bashing about it? (perhaps a void-stable-reprisitory??)


No its your fault to write bad code, just because it works in one compiler with one version doesn’t mean its meant to work.
You are most likely relying on undefined behavior and that’s a bug on your side, because you write code that doesn’t follow the standard.
gcc doesn’t break your code if its correct.


wasen’t there a guy who once calculated that the bumblebee, with all fysical meens, could not fly?

and I say the standard that did work has been alterd.
It is not only in my code. I remember like a few mounts ago I tried to compile the old school ‘iDesk’ (since it would fit my old school look of fluxbox). buth there again. the compiler (gcc) wanted me to make changes in the code in order to compile… estetic changes, it wanted me to put a space here and there, (a space between a ‘{’ and the rest of the code if I remeber it right)…

I admitt my code wasn’t the prittiest, but, spaces?!..
my bumbelbee flu, I tell you, it flu…