Notifications "Remove When Clicked"

[mikedvzo]

I am having trouble remembering but when I have Alfred send a Banner through Notification Center I thought it would stay up until I clicked on it.  There is in fact a setting under Advanced Preferences that says "Remvoed When Clicked" however all my notifications disappear within a few seconds if I have them set to Banners.  The only workaround is to set Alfred Notifications  as Alerts instead.  Am I remembering incorrectly and if so then what is this setting for?  

 

I am running 10.12.2 Beta (16C60b)

[vitor]

Remove when clicked simply controls if the notification will stay in Notification Center if you click to dismiss it.

Setting them as Alerts is not a workaround, it’s the official method.

[mikedvzo]

Thanks I figured as much just thought I remember it being different but I believe that goes back to when I used to use growl for notifications.  

[mikedvzo]

I remember now that I solved it in Alfred 3by sending this to a Bash Script Output:

 

echo "{query}" | /usr/local/bin/growlnotify --title "DNS Status" --sticky

[vitor]

26 minutes ago, mikedvzo said:

echo "{query}" | /usr/local/bin/growlnotify --title "DNS Status" --sticky

 

Don’t echo to a pipe. Instead do /usr/local/bin/growlnotify --title "DNS Status" --sticky <<< "{query}".

[deanishe]

11 hours ago, vitor said:

 

Don’t echo to a pipe. Instead do /usr/local/bin/growlnotify --title "DNS Status" --sticky <<< "{query}".

 

What's wrong with echoing to a pipe, btw?

 

[vitor]

1 hour ago, deanishe said:

What's wrong with echoing to a pipe, btw?

 

It’s not exactly wrong, just useless. It’s similar to UUOF (useless use of cat). It’s calling an extra process for something the shell could be handling.

Though in practice you’ll seldom (if ever) notice a difference and there is an (arguable) argument for legibility in select cases, I notice a reliance on this technique tends to lead to overuse. The examples on the Wikipedia page of catting to a command that could have just taken an argument are common.

Bash is a glue language, and one that tends to be used for quick things without much regard for correctness, as long as it works¹. As someone that likes to build big bash scripts I believe teaching these small details and proper ways of handling things will promote better use of bash in general².

 

---

 

¹ Though admittedly part of the reason it isn’t taken more seriously for bigger tasks is to do with the slew of workarounds it sometimes requires to not blow up in your face, especially when dealing with paths.
²Parameter substitution is another hidden gem. Frequently sed is used for changes that could be accomplished with a couple of characters.

Edited December 7, 2016 by vitor

[vitor]

Now that I think of it — and after a quick google search — it seems growlnotify shouldn’t even need it and just be passed something like /usr/local/bin/growlnotify --title "DNS Status" --sticky --message "{query}" or even /usr/local/bin/growlnotify --title "DNS Status" --sticky "{query}", which lends weight to the “overuse of cat and echo” argument. Naturally that all depends on what @mikedvzo would actually want (and I’ve never used growlnotify) but seeing as it is a command to output a message, it likely doesn’t need <<< or echo.

Edited December 7, 2016 by vitor

[deanishe]

2 hours ago, vitor said:

 

It’s not exactly wrong, just useless. It’s similar to UUOF (useless use of cat). It’s calling an extra process for something the shell could be handling.

Though in practice you’ll seldom (if ever) notice a difference and there is an (arguable) argument for legibility in select cases, I notice a reliance on this technique tends to lead to overuse. The examples on the Wikipedia page of catting to a command that could have just taken an argument are common.

Bash is a glue language, and one that tends to be used for quick things without much regard for correctness, as long as it works¹. As someone that likes to build big bash scripts I believe teaching these small details and proper ways of handling things will promote better use of bash in general².

 

---

 

¹ Though admittedly part of the reason it isn’t taken more seriously for bigger tasks is to do with the slew of workarounds it sometimes requires to not blow up in your face, especially when dealing with paths.
²Parameter substitution is another hidden gem. Frequently sed is used for changes that could be accomplished with a couple of characters.

 

Thanks for the explanation. echo is a built-in, unlike cat, so would there still be an extra process (due to the pipe, perhaps)?

 

The main reason I avoid using < or <<< is that I find putting the input at the end hinders readability. It violates the normally left-to-right flow, and I'm generally not a fan of short but cryptic variables and operators (which is why I usually write >/dev/stderr instead of >&2).

 

With things like parameter substitution or zsh's head/tail/extension modifiers, I can simply never remember the syntax or option names. For anything other than -f or -d, I always need to open test's man page.

 

That's also one of the two main reasons I gave up on Ruby and went with Python instead (the other being that Ruby sucked for non-ASCII text at the time).

 

[vitor]

Yes, I think that in the case of echo the pipe might be the bottleneck, but I’m not sure so don’t hold me to that. As I mentioned you’d likely never notice a difference in usage, so my argument is more about correctness than performance. Regarding parameter substitution vs sed you should indeed start to notice a slight performance hit.

I’d argue putting input at the end does not hinder readability significantly because most commands do get their input at the end. You typically do function_name function_arguments, not the reverse. The more you use < and <<<, the more natural and consistent with other commands it will be. Having said that, you can still take advantage of this features with the flow you mention. Taking the command from this thread, <<< "{query}" /usr/local/bin/growlnotify --title "DNS Status" --sticky would produce the same result. Same order, still no echo needed.

 

Readability is subjective, though, which is why the “arguably” caveat is needed. One should write code as they think it reads best (especially if no one else will ever read it) but at the same time it’s important to know the alternatives. I doubt there are many truly advanced bash users, as it’s common when trying to do more advanced stuff to have people suggest the use of a different scripting language. As such, I consider < and <<< to be obscure features to most users, as they never get to it (echoing and catting to a pipe comes naturally while learning) and important to reference to promote better bash usage.

 

I should have worded it differently in the original post, I now realise. The claim to “Don’t echo to a pipe” could be replaced with “Instead of echoing to a pipe”. That reads more as “I suggest this way” as opposed to “your way was wrong”, and that’s a fairer comment.

[deanishe]

<<< $var totally makes sense with a single command. The order of arguments is only an issue (for me) when piping several commands together and, particularly, when passing input to a multi-line loop. I don't think there's any reasonable alternative in that case, though, is there?

 

Best thing I ever did WRT shell scripting was switch to zsh to be honest. It takes a few of the roughest edges off bash.

 

I did rather get the impression you were saying there was something fundamentally broken with echoing to a pipe along the lines of "don't roll your own XML".

 

In any case, I'll bear your advice in mind and try to avoid using echo and cat with pipes in future. Thanks for the explanation.