Comment by ~scoopta on ~scoopta/wofi
I apologize for the late reply, I haven't had a lot of time for wofi. I'm hoping to get around to the issues that have piled up though. This is most likely caused by a bad line in your cache file. I'm working on a fix so that wofi will gracefully handle this condition but this can probably easily be fixed by either clearing your cache file in
$XDG_CACHE_HOME/wofi-drunor removing the bad line
Comment by ~scoopta on ~scoopta/wofi
I apologize for the late reply, I haven't had a lot of time for wofi. I'm hoping to get around to the issues that have piled up though. I'm unable to reproduce this with either tip or 1.2.4 no matter how many times I run it.
Comment by ~scoopta on ~scoopta/wofi
Hmmmmm, I tried creating an executable in my home folder(not in my path) and then linking it to /usr/local/bin but it shows up no problem. Wofi doesn't actually care about symlinks outside of directory links. That is it checks to see if the directories in
$PATHare links and if they are resolves them and uses their actual path, reason being to avoid doubling the entries on distros that link /bin to /usr/bin etc, however whether an executable is a link shouldn't matter. Wofi usesstat()to determine type of file andstat()resolves links so at no point should wofi even be aware of the link. I guess what I'm getting at is are you sure that's what's happening for you or is it just a coincidence? Actually...I bet I know what's happening. Is this related to #98 and the myriad of other optimization bugs reported? Easy way to test is does it happen with executables in your cache, if not do the executables show up if given enough time...if so...I really need to figure out a way to get that list populating faster or replace the FlowBox with something custom perhaps because there's so many people experiencing problems with how quickly wofi populates the results.
Comment by ~scoopta on ~scoopta/wofi
...ok so this is a very weird bug...apparently it depends on how fast you type in the search box, or something to that affect. I haven't fully traced it down but I have an idea of what could cause this
Comment by ~scoopta on ~scoopta/wofi
What version of wofi are you on? I recall this potentially being an issue in earlier versions but this should be fixed in current builds and I cannot reproduce it. As long as what I typed doesn't match any other results(the result box is empty) or I use argument parsing I get an error like
foo cannot be executed
Comment by ~scoopta on ~scoopta/wofi
Sorry for the late reply, I've been pretty terrible with responsiveness lately, wofi should show ANY file in
$PATHthat is executable, even symlinks. Pretty much the only requirement is that it be a regular file(symlinks included), it must be executable, and it must not have a duplicate named executable anywhere else in your path otherwise wofi will use the first occurrence and ignore future instances of it. As far as forcing wofi to use a certain path, run it with something likePATH=/my/custom/path wofi -Srun.
Comment by ~scoopta on ~scoopta/taiga
Yeah, taiga was kinda put together and then forgotten about. I'm the only one I know of that uses it. I'll definitely work on fixing this though