Evaluating the result of a bash script

[DerNils]

Hi there,

I'm a newbie to Alfred and completey overwhelmed by the possibilities of its workflows.

As such, I have a newbie question but google and the search engine of this forum could not help me.

In a workflow I'm using the (Action => Run Script) element to call a bash script that resides in my home folder. This bash script returns 0 in case everything is fine and a different number else. I'm now interested to evaluate this result but don't quite manage to get this done. 

Do I have to pass the result of the script into some variable of Alfred after calling the script? (at the moment the Run Script element only comprises one line).

The filter element looks like what I'm searching for but it is not quite working. Obviously the output from the script does not really end up in the filter....

Any suggestions would be greatly appreciated

Have a nice Sunday!

Nils 

[deanishe]

What do you mean "the script returns 0"?

 

It prints "0" or it exits with code 0?

[DerNils]

It exits with return code 0. 

Sorry for being imprecise.

Nils

[deanishe]

And what do you want to do with the exit status?

 

Can you give a more concrete description of what it is you're trying to achieve?

[DerNils]

Basically, I want to inform the user whether the script succeeded or not (as it has a certain chance to fail). To do so, I added a filter object behind the Run Script and post a notification.

 

I read a lot about the structure of workflows this evening and I think that the main issue is/was that I was calling the complete script instead of putting the steps of the script into the Run Script element. 

 

My new approach is now:

1) I added a variable to the workflow

2) I put the various steps of my bash script into the run script element. I can check for errors and set the workflow variable accordingly

3) In the filter I can then check for the value of the workflow variable and post a message. 

 

So far, this is not yet runnning. But I' hoping to be on a good way...

[deanishe]

The Post Notification action has a handy "Only show if the input has content" option. You can use that to "filter" the error message without having to set variables or use Filter objects.

 

Basically, anything your code prints to STDOUT is passed as input to downstream actions, while anything sent to STDERR ends up in Alfred's debugger.

 

So, the simplest way is to check the exit status and if it's non-zero, just echo your error message. As long as all the other output is redirected elsewhere, the notification won't be shown unless there's an error.

 

This is from a simple workflow I wrote to eject and trash mounted disk images:

 

log() {
	echo "$@" >/dev/stderr
}


log "name=$dmgname, mount=$dmgmount, path=$dmgpath"

# unmount
out="$( hdiutil detach "$dmgmount" 2>&1 )"
hds=$?
if [[ $hds -ne 0 ]]; then
	log "hdiutil exit status: $hds"
	log "$out"
	echo "$out"
	exit 1
fi

# trash disk image
out="$( osascript -e "tell application \"Finder\" to delete POSIX file \"$dmgpath\"" 2>&1 )"
oss=$?
if [[ $oss -ne 0 ]]; then
	log "osascript exit status: $oss"
	log "$out"
	echo "$out"
	exit 1
fi

log "trashed $dmgpath"

echo "Unmounted and trashed"

That script is connected to a Post Notification, which will either show "Unmounted and trashed" if everything went okay, or the output from hdiutil or osascript if one of them failed.

 

Edited November 6, 2016 by deanishe
Fix whoopsie Vítor spotted

[DerNils]

Wow, what a level of complexity this tool reaches. 

Thanks for pointing me into the right direction.  I now compiled my workflow together from your sample by using the Script Filter from another workflow. And the basic functionality is working.

 

Thanks for the support!

Have a nice week(end)

Nils 

[vitor]

1 hour ago, deanishe said:

log() {
	echo "$@" >/dev/stderr
}

log "trashed $dmgpath" >/dev/stderr

 

I might be missing something here, but why the >/dev/stderr in the bottom one? Isn’t that just repeating what the function itself does?

On another note, you can also >&2 instead of >/dev/stderr. That one I’m pretty sure you already know, so I’m leaving it here more as a reference for anyone else who stumbles upon this.

[deanishe]

1 hour ago, vitor said:

I might be missing something here, but why the >/dev/stderr in the bottom one? Isn’t that just repeating what the function itself does?

 

I probably just overlooked that when I added the log function and removed the other redirections. Will remove. Thanks!

 

1 hour ago, vitor said:

On another note, you can also >&2 instead of >/dev/stderr. That one I’m pretty sure you already know, so I’m leaving it here more as a reference for anyone else who stumbles upon this.

 

I prefer the clarity of /dev/stderr, at least when I don't have to type it all the time…