-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The workflow does not work #3
Comments
chumido, Thank you for opening an issue. I'm not quite sure what's wrong here, but I have some ideas if you wouldn't mind a bit of troubleshooting.
Thanks again, and sorry that the workflow didn't work for you out of the box. -jy-gh |
chumido, What OS version are you running? -jy-gh |
I'm running Ventura 13.3 |
chumido, Let's try this.
user.workflow.8A578702-C505-5035-8314-3FFF70C72130 from there, execute this command:
This should be the exact command that gets executed when you trigger the workflow with your configuration. If you get results back, that means that the problem is in the Alfred workflow itself, not the recent_files Python script. (If this is the case, save the directory and the above command to a file that's handy somewhere and I'll walk you through creating a workflow that uses the command.) If you get an error message, send me the error message. Thanks! -jy-gh |
It looks like the command wasn't entered quite right. Notice the "--fd-commannd /usr/local/bi/fd", above. That should be "--fd-command /usr/local/bin/fd". You should be able to copy/paste this directly--as long as you're in the correct workflow directory:
|
chumido, Wow. My guess is that your You can test this by running
You should get a similar error. (And if that binary is bad, for whatever reason, you might consider renaming it or deleting it altogether.) If the problem is with
I don't know how involved it is to set up a Rust programming environment if you're not a HomeBrew or MacPorts user. (If you don't use either MacPorts or HomeBrew, you might consider installing one of them--I personally prefer MacPorts but it's up to you as there are pros and cons to each--as it makes installation of tons of useful programs as easy as the commands in Option 1 or Option 2, above.) Let me know what you find out. -jy-gh |
i runed this |
Ah. Maybe I was too quick to blame Can you copy/paste this line into a terminal window? (Keep in mind that it's all one line, despite how it might look in GitHub.)
It should create a temporary file called "testfile" (you can change the name if you like), then print out something like "1670512374.69967" (it's a timestamp, so you won't get exactly what I show here), and then delete the "testfile" temporary file. If it doesn't print out the timestamp number string perhaps the problem is with Python. The following command may be helpful:
-jy-gh |
Well, I did some more research on that error message, and I found this fairly recent bug report: std::fs::Metadata timestamp methods will panic on files with invalid timestamp nsec values If you check this report you'll notice that the error is the exact same one you're experiencing. I don't fully understand the issue--I don't know anything about the Rust programming language--but what it's appearing to say is that it's possible for a file to be created that has an invalid timestamp. The timestamp, which in Unix-like systems such as macOS is represented as a large number, has a definite limit, and if the number is larger than the limit, it crashes programs relying on the included Rust library code. I'm guessing, still, that this has to do with the Now, if there were only a few problem files with invalid timestamps we could use the ignore-file feature of RecentFiles as a workaround to avoid checking those files. But, there might be a lot of these files, and finding them sounds like a very difficult task. I have a couple of suggestions. Before that, though, I didn't ask you how you installed
If these don't work I'm not sure how to proceed. I would think that the Rust bug will be fixed, but I don't know how soon, and I don't know how long it will take a fix to be pushed to |
chumido, I did make a minor fix to the workflow that I found because of your issue. You should re-download the workflow file (v0.8.4) and use it instead. While it won't fix the issue you're encountering, it will make it easier to use an alternate -jy-gh |
Thank you very much. I tried:
But it still not work. Get the same error. So weird 😅 |
Just to make sure, you changed the configuration value for the "Path to the fd command" to each of the HomeBrew (probably [Edited to put the full path to the MacPorts |
There are a couple additional things we can try. One of them will take some extra work on my part, so I don't have it ready just yet, but if you're willing I'll code it up. The other thing you can try is to try a similar workflow--in fact, it was this workflow that inspired me to write Recent Files--called Last changed files. That should work, and it will get you the feel of Recent Files even if it's not as speedy in all cases. |
Yes. I changed the path everytime i re-install. |
chumido, Okay. I coded up a Ruby version of recent_files. It's attached. Here's how to install it: First, find the directory where recent_files is located, using the procedure that you used before:
From there, find the RecentFiles workflow directory with something like this:
cd to that directory. It will be something similar to this:
Make a backup copy of
Then copy the attached Ruby file into this directory, naming it It should be a drop-in replacement, and shouldn't need any changes. Give it a try. I tested it, but of course there's the possibility that I missed a problem with it--and of course I make no guarantees about its suitability, etc. (My version of Ruby is 3.2.1, but I don't think the code depends on anything version-specific.) If it works, that means the problem is somehow connected to your Python installation/version. If it doesn't work, it means that whatever version of the If it does work, I will consider making it part of the repository here. (The Python version is a tiny bit faster, so that's still my preference.) Let me know how it works. -jy-gh |
chumido, I'm sorry, I left out an important step. The
After that's done,
Keep the language field in Alfred as /bin/bash. The script itself has a pound bang line of
That's why it gave you the permission denied error. Sorry, that was my bad. -jy-gh |
chumido, Hm. First, let's reset the workflow's arguments to the defaults. If you view the workflow in Alfred's preferences by clicking on the Workflow icon and then selecting the workflow you'll see the Configure Workflow button. Click that and then click on the Reset to Defaults button on the bottom left. Then click Save. (Note that this will still use the Ruby version of recent_files, as that's all it can find.) Give the workflow a try then. (And, if it still doesn't work, choose a smaller folder to search, such as your ~/Desktop folder or your ~/Downloads folder, and perhaps also lower the Changed within value in the workflow configuration to 3d or even 1d.) After that, how about this: Go back to your workflow directory and execute recent_files directly:
Do you get results? (It'll be a screen full of a JSON structure with a lot of filenames.) If you get an error, I'd like to see the error. If you get results, you don't have to send me those (they'll be your files and I don't need to see the filenames or anything), but I would like to know if this worked or not. (And FYI, I did try running the Ruby version of You can, if you like, repeat this experiment with the Python version:
Now, after doing that, we could test your theory about a conflict. It's possible, from the Alfred Workflow screen (the screen that shows all your Alfred workflows) to disable all the installed workflows except for the Recent Files workflow. If the problem still persists after that I think that proves that there's no conflict. If, on the other hand, it starts working, then what you can do is to re-enable each workflow, one at a time, and try Recent Files after doing that. By going one at a time, if there's a conflict, Recent Files will stop working at some point. Whatever the last enabled workflow was would seem to be in conflict with Recent Files. We can look at that in more detail if you find this happening. (Make sure you remember to re-enable your workflows after this experiment so that we don't leave something disabled that you rely on!) If we get to this point and things aren't working I should have you double check some ordinary Alfred settings. From the Alfred preferences, click on the General icon. From there, click on the "Request Permissions..." button.
Next, click on Features (on the left, under General--the Alfred hat icon). Here's what mine looks like: From there, click on Universal Actions. Here's what mine looks like: Let me know what you find out--and thank you for your persistence and your patience. -jy-gh |
chumido, I saw that you edited your response--and you are totally on the right track by changing the You are saying here that what's going on is that you are seeing results from (as an example) the Pictures folder even though it's in your How are you editing the Check this post, especially the top two answers, to find out what line ending characters are being used in the This article, in the Git Ignore Patterns section, gives a lot of examples on how to create entries in a I do notice that the Applications (Parallels) and Calibre Library directories aren't correctly listed. They'll either need to be enclosed in quotes, or any spaces need to be escaped with a backslash "\" character, such as shown in this post. -jy-gh |
I would guess at some point that line endings will cause you confusion if you exchange files between a Windows system (including Parallels) and a Mac, so it's worth a little discussion. Basically, Unix/macOS and Windows text files use slightly different characters as end of line (EOL) characters--and you don't normally see them. DOS/Windows uses two characters, the Carriage Return and the Linefeed characters. Unix--and macOS since OS X--use (only) a Linefeed. These will be invisible in editors such as TextEdit and it's possible to interleave the two line endings in a file, so what you don't see can confuse you by producing garbled output. Now, on to creating a file that has what you need. Try copy/pasting this entire command below into a
There's a command, As a test, I created Unix/macOS and DOS/Windows files, and a file with both kinds of line endings. Here's what
Notice that The other two files show end of line characters that may present problems to any number of Unix/macOS programs if they're not specifically prepared to handle different line endings. (And by problems, I mean also that the program could work as intended, but not as expected by you.) One last thing: when you create this file you should make sure that the Recent Files workflow refers to the correct ignore file. (I'd get rid of example_ignore_file.txt just to prevent any confusion later.) If all this works for you I'm going to close this issue, but I'll leave it open for awhile just to make sure that you're up and running. |
chumido, Are things working? --jy-gh |
chumido, First, maybe either kill all those fd and python processes--as long as they aren't something different that's important!--or reboot. Then, try the Ruby version in place of the Python version. Does the Ruby version do the same thing? --jy-gh |
chumido, Okay. We're going to try something different. There's an easy, but limited way to do what I'm suggesting, and then there's a more complicated, but potentially much more useful way to go about this. The easy way is just to change the Top-level directory used by the workflow to a specific directory and see how things go. I'm thinking that will work, but it means that you'll only get results from that specific directory (such as your ~/Documents directory). The harder way involves more steps, but you could end up with Recent Files being able to search most, if not all, of the directories that you really wanted. Here's how to do things the more complicated way: I will attach modified version of both the Python and the Ruby recent_files scripts. The thing that's different about them is that they will follow symbolic links. (I'll explain what I mean by that in a bit.) Firstly, make a directory somewhere--your $HOME directory is fine. I'll call it example_dir for this, but you can call it whatever you like, and it doesn't have to be in your $HOME directory (or ~, which is the same as $HOME). Just keep it consistent for the rest of this.
Now, instead of having recent_files try and traverse your $HOME, we're going to point it to this directory, only. In the Configure Workflow screen, change the Top-level directory to the new directory you just created. If you ran the Recent Files workflow now, you'd see nothing, since there's nothing in the directory--but it should run correctly. Now, what I'll have you do is to create symbolic links to whatever directories you want to search in the example_dir directory, one at a time. Let's start with your Documents folder.
What that does is create a symbolic link to the ~/Documents folder inside example_dir. So, from example dir, you could Right now, the version of the recent_files Python and Ruby scripts that you have won't correctly handle following symbolic links, so I have created new versions that will. (I think that's a useful feature, and I'll add it to the upcoming version of the Recent Files workflow that I will soon be preparing for release.) After you download them, you'll have to rename them in order to use them. (I had to use .txt extensions as only some file extensions are allowed.) Of course, you can only use one of them at a time. Also, you'll have to keep straight which one of the now 4 files that you have is named recent_files--the current Python version, the experimental Ruby version, and now these two: recent_files.python_linkfollower.txt After downloading these files, pick one of them and copy it to your workflow directory, being careful to preserve the other existing recent_files versions in some fashion. (I guess you can always re-download them if you need them, so it's not the end of the world if there's some confusion.) Now, after renaming, say, If that works, you can add some additional directories to the example_dir directory, such as these:
Here's what an
Notice the initial lowercase 'L'? That indicates that the file is a symbolic link. It's probably best not to add too many directories at once. (I still feel like there's something in your filesystem that is causing this weirdness.) If you use the workflow, and it works, then you can add another directory. Sooner or later my guess is that you'll find a directory that makes the workflow fail, and you'll want to carefully delete that symbolic link from ~/example_dir using the macOS Finder, not the Unix I want to stress that you should use the Finder to delete things, as you can always restore a deleted file or directory from the Trash, but if you use The rationale for doing all this is that previously, we tried to blacklist directories using an ignore-file. Now, what we're doing is the reverse, whitelisting directories that you want to search. Again, I'm sorry that this has been so difficult. I still have no real idea what is going on with your system to cause this behavior. --jy-gh |
chumido, Thank goodness. I'm very happy that this is working for you. I will think about how best to support this in a future release. The follow symbolic links part is easy, but what would really be nice would be a directory-picker feature in Alfred's configuration that allowed multiple selections. Then, instead of having to create a directory and put symbolic links in it, you'd simply use the directory-picker to choose as many directories as you like. Unfortunately, Alfred's file/directory-picker only allows a single selection. I'll look into this a bit. --jy-gh |
Please check
The text was updated successfully, but these errors were encountered: