Jump to content

RecentlyAdded — List directory contents by added date


Recommended Posts

8 minutes ago, deanishe said:

Shell languages like bash and zsh are pretty inscrutable, and are only well-suited for very simple tasks.

 

I agree. Yet, I disagree with the sentiment that they’re inadequate and that someone should learn python or ruby first, precisely because when you’re starting out all you want to and can do are simple tasks.


More than a handful of times I’ve seen python scripts with five lines that import system libraries to do something that can be done in a single line of bash with one or two pipes. No doubt from someone that opted to learn python before bash. This is not to bash (eh) on python at all; for some reason it’s the language I’ve seen this happen more often.


Starting to learn a programming language when you don’t even know what a terminal is requires a lot of mental boilerplate from. With bash, you open a terminal and it’s there. “Hey, try to type ls”. Bam, you recognise those, don’t you? Those are your files and directories on your home. “Now try cd followed by the name of a directory. Looks like nothing happened, but that’s normal; try ls again. As you might’ve already guessed from the new result, you switched to that directory you typed previously. That’s what cd (change directory) does”.


And then later you learn about similarly easy commands like mv and cp. Then you learn about wildcards and one day you plug in your camera to your computer and want to separate the videos from the pictures and you realise “hey, I can just mv *jpg /some/path to do that!”.


I strongly disagree with the general message of “think of what you want to build and then learn how to do it”. When you know nothing about programming you have no idea what you want to build or how to go about it. If you do, there’s a good change it’s too complex to be a starting project.


Shell scripting is rewarding. You need very little to start and you quickly feel “hey, I’m doing things”. It’s easy to add commands to your repertoire one at a time and build on that. It also has real results on your data, which is exciting and immediately useful (and dangerous). That’s an incentive to learn more. If you do enough of it, there’ll be a time when you’ll realise “alright, the limitations I’m encountering over and over are becoming frustrating; time to learn something else”. And when that happens, learning other scripting languages will be easier.

Link to comment
5 hours ago, vitor said:

precisely because when you’re starting out all you want to and can do are simple tasks.

 

Often very true. It’s just that when you come back to add some more features to your script, depending on what it is, you can run into the limits of bash/zsh very quickly.

 

The Script we’re talking about here needs to call Perl — a full scripting language — to ensure valid output.

 

5 hours ago, vitor said:

you have no idea what you want to build or how to go about it. If you do, there’s a good change it’s too complex to be a starting project.

 

I disagree with this notion, as we’re on the Alfred forum. A little bit of code can go a long way in a workflow.

 

And I think workflows are an excellent way to start coding. But bash/zsh are a bad choice for them, as they just don’t support the features you need.

 

Sure, if you want to write CLI scripts, zsh is a decent place to start (better than bash, imo). If you want to write dynamic webpages, then PHP and/or JS are reasonable choices.

 

But if you go with workflows, I think you’re better served with Ruby or Python.

 

5 hours ago, vitor said:

and dangerous

 

This is a particularly nasty feature of shell scripting. It’s very, very easy to make mistakes due to the funky string handling and special characters.

 

5 hours ago, vitor said:

the limitations I’m encountering over and over are becoming frustrating; time to learn something else

 

You think that way, and so do I, but an awful lot of people are in the “if the only tool you have is a hammer, everything looks like a nail” camp (I’m looking at you, people who write workflows in Node).

 

In either case, learning Ruby or Python will get you a lot further before you run into any “wrong tool for the job” wall.

 

5 hours ago, vitor said:

And when that happens, learning other scripting languages will be easier.

 

I’d say it’s the other way around. Bash has weird syntax, cryptic shorthand, crappy typing and awful error handling.

 

Better to learn a language with sensible typing and error handling first, so you’re aware of the lack of those things when you start playing with bash in earnest.

Link to comment
9 hours ago, deanishe said:

(I’m looking at you, people who write workflows in Node)

 

Just yesterday I saw a node app that toggles Do Not Disturb with AppleScript. It was basically the necessary AppleScript code bundled inside a lot of unnecessary JavaScript boilerplate.


That’s kind of my point with shell scripting. Simple things are easier to do, so you if you’ve never programmed and think programming will be hard, starting with something where you immediately see results with little code is encouraging to keep trying.


In that same vein, I also think Processing is a nice language to learn. Yes, the language itself can be a bit much (Java), but since you’re putting images on the screen so easily, it’s rewarding.

 

9 hours ago, deanishe said:

as we’re on the Alfred forum. A little bit of code can go a long way in a workflow.

9 hours ago, deanishe said:

And I think workflows are an excellent way to start coding.

9 hours ago, deanishe said:

But if you go with workflows, I think you’re better served with Ruby or Python.

 

In that sense, I agree. Putting code inside a Workflow’s script editor is equally easy in any language (that comes bundled with macOS) so might as well do it with the good ones.

Link to comment
4 hours ago, vitor said:

Just yesterday I saw a node app that toggles Do Not Disturb with AppleScript. It was basically the necessary AppleScript code bundled inside a lot of unnecessary JavaScript boilerplate.

 

Absolute madness.

 

4 hours ago, vitor said:

Simple things are easier to do, so you if you’ve never programmed and think programming will be hard, starting with something where you immediately see results with little code is encouraging to keep trying.

 

I do agree with that, but bash has some really sharp edges, which turn things that should be pretty simple, like string manipulation, into a nightmare.

 

Remember how many problems escaping caused in Alfred 2. Even some of the demo workflows had incorrect settings.

Link to comment

Update.


Added official support to sorting by date added. Rewrote the Workflow in ruby to fix something else and decided to add it in.

 

In the case of sorting by added, results are cached until the directory is modified, which should keep it fast.


To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Link to comment

@vitor Thanks for updating the workflow!

 

Unfortunately, I can't seem to get the new keywords working (rda & rdz) (rdn & rdo - work fine). When I click them they run for a second and then my fallback searches show up. I've tried restarting a few times and even downloading new files, but I haven't had any luck. Any suggestions? Thanks!!

Link to comment
  • 5 months later...
  • 5 months later...
  • 5 months later...
On 10/22/2018 at 8:38 AM, vitor said:

Update.


Allow using a different directory by changing a Workflow Environment Variable.

 

 

Thanks Vitor, I've successfully changed the Workflow Environment Variable in the .plist file. I would love to use this for directories in other volumes as well. I have many folders in which I frequently check the recent contents, but they are on '/Volumes/HDD/...'    not '~/...'

 

Any way you can modify the workflow to choose directory variables on volumes other than 'HOME'?

Link to comment
20 minutes ago, phantasm said:

Any way you can modify the workflow to choose directory variables on volumes other than 'HOME'?

 

Grab the latest version (just released).

 

Modified it to no longer take paths relative to the home directory.

Link to comment
3 minutes ago, phantasm said:

rda and rdz are still showing hidden files.

 

Because your results are cached (the contents of the directory haven’t changed, just the information being displayed in Alfred). Next time you change something in the directory, it’ll fix itself. Alternatively, delete ~/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/com.vitorgalvao.alfred.recentdownloads to get rid of the cache.

Link to comment
3 minutes ago, vitor said:

Because your results are cached (the contents of the directory haven’t changed, just the information being displayed in Alfred). Next time you change something in the directory, it’ll fix itself. Alternatively, delete ~/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/com.vitorgalvao.alfred.recentdownloads to get rid of the cache.

 

 

Yep, that was it. Thanks!

Link to comment
  • 1 month later...

Update.

 

When building the list with rda or rdz, the cache file won’t be saved when there are incomplete files (downloads in progress). In addition, cache checking is now done with a single file.


To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.
 

Edited by vitor
Link to comment

Updates.

  • When clearing the cache, reopen in the same option we were in.
  • Changed cache clear option to use ⇧ instead of fn.
  • Label nodes and add colours, to make connections easier to see.

To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.
 

Edited by vitor
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...