Jump to content

ENOENT & path issues (bash + nodeJS)

Recommended Posts

Hey everyone,


here's one I can absolutely not figure out for myself:


if have this very simple bash script called launcher.sh



${node} test.js &> node-out.txt &

and a quite simple node script called test.js

	src:"a.jpg", dst:"b.jpg",
	width:60, height:60
function(image) {
function (err) {

If i call from the terminal node test.js or ./launcher.sh, then everything is fine (I get image a.jpg to be cropped and written to b.jpg), but if i trigger it through a script filter containing only ./launcher.sh, then i get this error:


[Error: File not supported.]
and I have tried with another less used npm package for test.js:
var resizeCrop = require('resize-crop');
		format: 'jpg',
		src: "a.jpg",
		dest: "b.jpg",
		height: 60,
		width: 60,
		gravity: "center"
	}, function(err, filePath){
		if(err) console.log(err);
		else console.log("success");

which throws a more verbose error when triggered from a script filter:

        throw er; // Unhandled 'error' event
Error: spawn ENOENT
    at errnoException (child_process.js:1001:11)
    at Process.ChildProcess._handle.onexit (child_process.js:792:34)
Do you guys have any idea why it works from the terminal but not from alfred? On my real script, I'm writing/reading other files and i never have any issues with it...
Link to comment

If it works just fine from the console but doesn't work from inside Alfred, then it's probably because there are some environmental variables set in your shell that aren't available in Alfred. For testing purposes try putting 

source /Users/USERNAME/.bash_profile

near the top of the launcher script and see if it works.


If it solves it, then this method is fine for personal workflows, but it shouldn't be used in a workflow that you're going to distribute because you can't rely on the same profile settings.

Link to comment

Yes, it does solve it. But what can I do to have it work on other people's computers then?


For info, here's my .bash_profile

export PATH="/Users/Flo/Library/Application Support/GoodSync":$PATH
# Your previous /Users/Flo/.bash_profile file was backed up as /Users/Flo/.bash_profile.macports-saved_2014-05-10_at_17:16:41

# MacPorts Installer addition on 2014-05-10_at_17:16:41: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.

# Your previous /Users/Flo/.bash_profile file was backed up as /Users/Flo/.bash_profile.macports-saved_2014-05-10_at_17:22:00

# MacPorts Installer addition on 2014-05-10_at_17:22:00: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.

export PATH=/usr/local/bin:$PATH
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments

and if it's of any help:

Flo$ echo $PATH
/usr/local/bin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Users/Flo/Library/Application Support/GoodSync:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/CrossPack-AVR/bin:/usr/texbin
Edited by Florian
Link to comment

If it works in a script but doesn't work in Alfred, it's always something about the Path settings. Every time.


So... is this a workflow that you're making just for yourself, or is it one that you're going to distribute? If you're going to just use it on your own, then you could probably just symlink the tool.


If you're going to distribute it, then things get more complicated:


If I remember right, ImageMagick is pretty big and often needs to be compiled on the machine because it uses linked libraries, which will often make it fail if distributed otherwise. I know you can compile ImageMagick to be stand-alone (but this standalone would need to be tested on different versions of OS X to make sure that it runs 10.6–10.10, or whatever versions you choose to support). If you can find a way to compile it


That being said, the user also needs to have node installed, which runs into the same problems above.


So, if you're going to distribute it, you might write up that it needs to have homebrew, nodejs, and imagemagick installed, and then you could just include an install script that will install homebrew (if necessary), nodejs (if necessary), and imagemagick (if necessary). Just make sure that they exist first (for the bash commands, just use "which brew", etc...). That would probably be the best way to make it work because of the number of dependencies that this has.

Link to comment

Well I'll see about distribution. Ideally I'd want it to be out there, seems more fun that way. But what i'm making is in the same vein as my other frowned upon workflow (piratebay): when i'm done with this one, just typing the keyword will display all the tv shows I follow that have available new episodes and offer to stream them.


But yeah I guess the install script would be optimal.

Link to comment

Oh, and they might also need to download xcode tools... so make sure that you put that in the instructions.


The other option would be to try to find things that work more natively. I know that you can use `sips` to resize images just fine, so you won't need ImageMagick for that. You can look to see some stuff about sips on this thread. I also used it in the newer (still unreleased) version of the bundler to convert images between different formats.


While coding stuff for Alfred, I have learned that there are a lot of nice tools that already are on OS X that can be used for many things, even if they aren't the most powerful.

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...