Mountain Lion behaves differently with regard to sleep than Lion and earlier (I think disk activity does not affect the sleep timer in Energy Saver, only keyboard and mouse activity). This causes problems for several programs. Jiggler or Caffeine used to work to keep the machine awake, but no longer do so.
Apple have introduced a new command, caffeinate., to prevent sleep. That works fine to set a period of time to remain awake. But the manual says that it can be used to keep awake while a program is running. I (and others, it has been reported in the Apple forums) find that I get "permission denied" when I try to do this.
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
I would expect the command to work even as a standard user, but have found that it does not even work as an admin user, or as an admin user with sudo.
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Lewis g.kreme@redacted.invalid wrote:
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Sorry if I wasn't clear enough.
The manual for caffeinate seems to say that the command
caffeinate -di /path/to/Application.app
should work (to stop sleep while the application is running).
Simple and straightforward command, on the surface.
But all my attempts (different applications, different users) lead to the same reponse, which is
permision denied.
In article 1kow4w8.1pl3qu3pq89fkN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Lewis g.kreme@redacted.invalid wrote:
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Sorry if I wasn't clear enough.
The manual for caffeinate seems to say that the command
caffeinate -di /path/to/Application.app
should work (to stop sleep while the application is running).
Simple and straightforward command, on the surface.
But all my attempts (different applications, different users) lead to the same reponse, which is
permision denied.
Maybe you need to run it with sudo.
In article 1kow4w8.1pl3qu3pq89fkN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Lewis g.kreme@redacted.invalid wrote:
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Sorry if I wasn't clear enough.
The manual for caffeinate seems to say that the command
caffeinate -di /path/to/Application.app
should work (to stop sleep while the application is running).
Simple and straightforward command, on the surface.
But all my attempts (different applications, different users) lead to the same reponse, which is
permision denied.
caffeinate -di
/Applications/QuickTime?Player.app/Contents/MacOS/QuickTime?Player
You are in the shell, so you want Unix executable programs, NOT directories, which is all that a .app file is, a directory with all the resources for the Mac OS X GUI app.
You might try:
caffeinate -di open -a /path/to/Applications.app
where 'open' is a Unix executable, that knows how to launch Mac OS X GUI Apps.
Daniel Cohen dcohenspam@redacted.invalid wrote:
Lewis g.kreme@redacted.invalid wrote:
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Sorry if I wasn't clear enough.
The manual for caffeinate seems to say that the command
caffeinate -di /path/to/Application.app
should work (to stop sleep while the application is running).
That isn't how it works. (I agree that the man page is vague.)
caffeinate with the optional utility and arguments parameter is used to launch a utility (such as another command line tool) and prevent various forms of sleep while the utility continues to run. This might be useful to run something time consuming like rsync, for example.
It doesn't detect an already running instance of the utility, and can't directly launch an application using the above syntax. You are getting "permission denied" because a folder is not an executable utility.
Even if your utility was the "open" command and you used it to launch an application, caffeinate would only keep the system awake while the application was being launched. "open" causes the application to be launched as an independent process by launchd, after which it runs independently of Terminal, the shell and caffeinate.
You might be able to get some applications to run through caffeinate by directly invoking the executable file within the application, but this would result in the application being a child process of caffeinate, the shell and Terminal, so if you stopped any of those, it would cause the application to immediately terminate (effectively a force quit).
The general syntax for that would be:
caffeinate -di /path/to/AppName.app/Contents/MacOS/AppName
Looks to me like caffeinate should be designed to accept a pid as input. It would then prevent system to sleeep as long as that pid exists.
So you start your GUI app, find its pid, give it to caffeinate.
On 08-15-2012 21:35, David Empson wrote:
Even if your utility was the "open" command and you used it to launch an application, caffeinate would only keep the system awake while the application was being launched. "open" causes the application to be launched as an independent process by launchd, after which it runs independently of Terminal, the shell and caffeinate.
Although 'open' does have a command line switch that says "Don't return to shell until the app quits"
In message 1kow4w8.1pl3qu3pq89fkN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
Lewis g.kreme@redacted.invalid wrote:
In message 1kovy4h.u0ig7fl2q0rqN%dcohenspam@redacted.invalid Daniel Cohen dcohenspam@redacted.invalid wrote:
I may well be doing something wrong, but the manual does not indicate any syntax that I have got wrong.
Does anyone know what is happening and what I should be doing?
Since no one know what you are doing, it is impossible to answer that.
Sorry if I wasn't clear enough.
The manual for caffeinate seems to say that the command
caffeinate -di /path/to/Application.app
should work (to stop sleep while the application is running).
Highly unlikely.
Try
/path/to/Application.app/Contents/MacOS/application
Wes Groleau Groleau+news@redacted.invalid wrote:
On 08-15-2012 21:35, David Empson wrote:
Even if your utility was the "open" command and you used it to launch an application, caffeinate would only keep the system awake while the application was being launched. "open" causes the application to be launched as an independent process by launchd, after which it runs independently of Terminal, the shell and caffeinate.
Although 'open' does have a command line switch that says "Don't return to shell until the app quits"
Ah, that looks more promising. Well spotted, that man. Not an option I'd looked at before, but I see it existed at least as far back as 10.6.8.
Trying this...
caffeinate -di open -W /path/to/AppName.app
or for applications in a standard location such as /Applications:
caffeinate -di open -Wa AppName
Testing with display set to sleep after 1 minute of inactivity...
Yes, this seems to work. No display dimming or sleep after a couple of minutes. The caffeinate and open commands keep running until you manually stop them (Ctrl-C) or quit the referenced application.
It even works if the application was already running when you used the caffeinate command, since open will normally activate an already running application rather than launching a new instance. (There is an option to open another instance, but some applications won't like that.)
David Empson dempson@redacted.invalid wrote:
Ah, that looks more promising. Well spotted, that man. Not an option I'd looked at before, but I see it existed at least as far back as 10.6.8.
Trying this...
caffeinate -di open -W /path/to/AppName.app
or for applications in a standard location such as /Applications:
caffeinate -di open -Wa AppName
Testing with display set to sleep after 1 minute of inactivity...
Yes, this seems to work. No display dimming or sleep after a couple of minutes. The caffeinate and open commands keep running until you manually stop them (Ctrl-C) or quit the referenced application.
It even works if the application was already running when you used the caffeinate command, since open will normally activate an already running application rather than launching a new instance. (There is an option to open another instance, but some applications won't like that.)
Thanks to you, Wes, and others for explaining things to me very clearly. If only the manual pages had given proper examples of this.
I would like to do this as a shell script. I can probably work that out myself without much trouble.
In article 1kowtk2.t2wy0jbydayeN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Thanks to you, Wes, and others for explaining things to me very clearly. If only the manual pages had given proper examples of this.
As someone who is self-taught in UNIX (HaHa, HoHo, & HeeHee), the man pages have always seemed to be perfunctory, pro forma boilerplate, deliberately minimalist so that the developers can claim they had provided help, but not cost them much effort, and yet allow them to look down their noses at the neophytes who are quite rightly confused by the lack of real instruction.
In article fmoore-5A4CBA.15451316082012@redacted.invalid, Fred Moore fmoore@redacted.invalid wrote:
In article 1kowtk2.t2wy0jbydayeN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Thanks to you, Wes, and others for explaining things to me very clearly. If only the manual pages had given proper examples of this.
As someone who is self-taught in UNIX (HaHa, HoHo, & HeeHee), the man pages have always seemed to be perfunctory, pro forma boilerplate, deliberately minimalist so that the developers can claim they had provided help, but not cost them much effort, and yet allow them to look down their noses at the neophytes who are quite rightly confused by the lack of real instruction.
They're generally intended to be references for people who know what they're doing, not tutorials for beginners. You have to know what the command is for in general, and then you can use the man page to find out the details of options.
On 08-16-2012 15:45, Fred Moore wrote:
In article 1kowtk2.t2wy0jbydayeN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Thanks to you, Wes, and others for explaining things to me very clearly. If only the manual pages had given proper examples of this.
As someone who is self-taught in UNIX (HaHa, HoHo, & HeeHee), the man pages have always seemed to be perfunctory, pro forma boilerplate, deliberately minimalist so that the developers can claim they had provided help, but not cost them much effort, and yet allow them to look down their noses at the neophytes who are quite rightly confused by the lack of real instruction.
It's better now, but when OS X first came along, Apple included the BSD man pages without editing in the changes they had made.
Wes Groleau Groleau+news@redacted.invalid wrote:
It's better now, but when OS X first came along, Apple included the BSD man pages without editing in the changes they had made.
Which may explain why I cannot understand the -a flag for 'open' which does not appear to act in the way the manual describes.
Incidentally, since I am posting again, caffeinate allows the flags -d (no display sleep), -i (no idle sleep) and -s (no System sleep). What is the difference between -s and -i (or possibly -di)? I suspect it may only be relevant for laptops.
For anyone who is interested, I can now write a shell script that prevents sleep in Mountain Lion independently of specific applications (by running a dummy application, and pushing it and Terminal into the background). I will post it in the "help with caffeinate" thread in Apple support communities Mountain Lion section, once I am awake.
On Thu, 16 Aug 2012 15:45:13 -0400, Fred Moore wrote:
In article 1kowtk2.t2wy0jbydayeN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Thanks to you, Wes, and others for explaining things to me very clearly. If only the manual pages had given proper examples of this.
As someone who is self-taught in UNIX (HaHa, HoHo, & HeeHee), the man pages have always seemed to be perfunctory, pro forma boilerplate, deliberately minimalist so that the developers can claim they had provided help, but not cost them much effort, and yet allow them to look down their noses at the neophytes who are quite rightly confused by the lack of real instruction.
I find understanding them comes with practice. The attitude you are describing certainly seemed to apply a dozen years ago. I asked a question about a utility which didn't have any documentation at all and was told to read the source...
Yeah, right. I had the full 6 or 7 CD Linux set packed with thousands of utilities. I was certainly not going to plough through the sources of that little lot.
In article 1koybcv.11wonjhgqh2iaN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Wes Groleau Groleau+news@redacted.invalid wrote:
It's better now, but when OS X first came along, Apple included the BSD man pages without editing in the changes they had made.
Which may explain why I cannot understand the -a flag for 'open' which does not appear to act in the way the manual describes.
I don't see how that could explain it, since 'open' is a Mac command that didn't exist in BSD.
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
It also works if I give the full path to the application:
open -a /Applications/TextEdit.app filename.docx
However, if you use the second form, you have to remember the .app suffix. Maybe that's the problem you ran into.
Barry Margolin barmar@redacted.invalid wrote:
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
Yes, that's fine, the manual explains what
open -a application file
does, but one has to have more experience than I have to realise that this also covers
open -a application
That was explained to me by David Empson in a thread related to this on the Apple Support Communities Mountain Lion section
In article 1koznr4.sxbt921me61qgN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Barry Margolin barmar@redacted.invalid wrote:
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
Yes, that's fine, the manual explains what
open -a application file
does, but one has to have more experience than I have to realise that this also covers
open -a application
That was explained to me by David Empson in a thread related to this on the Apple Support Communities Mountain Lion section
You can also do such as:
open -a Safari 'http://www.example.com/'
which I have found very handy.
In message timstreater-330B0F.23260317082012@redacted.invalid Tim Streater timstreater@redacted.invalid wrote:
In article 1koznr4.sxbt921me61qgN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Barry Margolin barmar@redacted.invalid wrote:
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
Yes, that's fine, the manual explains what
open -a application file
does, but one has to have more experience than I have to realise that this also covers
open -a application
That was explained to me by David Empson in a thread related to this on the Apple Support Communities Mountain Lion section
You can also do such as:
open -a Safari 'http://www.example.com/'
which I have found very handy.
I usually just say
open http://www.example.com
In article slrnk2thqu.eqs.g.kreme@redacted.invalid, Lewis g.kreme@redacted.invalid wrote:
In message timstreater-330B0F.23260317082012@redacted.invalid Tim Streater timstreater@redacted.invalid wrote:
In article 1koznr4.sxbt921me61qgN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Barry Margolin barmar@redacted.invalid wrote:
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
Yes, that's fine, the manual explains what
open -a application file
does, but one has to have more experience than I have to realise that this also covers
open -a application
That was explained to me by David Empson in a thread related to this on the Apple Support Communities Mountain Lion section
You can also do such as:
open -a Safari 'http://www.example.com/'
which I have found very handy.
I usually just say
open http://www.example.com
Fine but I needed Safari to do it.
On 08-17-2012 02:29, Daniel Cohen wrote:
background). I will post it in the "help with caffeinate" thread in Apple support communities Mountain Lion section, once I am awake.
An ironic ending when the subject starts with "caffeinate"
In message timstreater-F54046.23480417082012@redacted.invalid Tim Streater timstreater@redacted.invalid wrote:
In article slrnk2thqu.eqs.g.kreme@redacted.invalid, Lewis g.kreme@redacted.invalid wrote:
In message timstreater-330B0F.23260317082012@redacted.invalid Tim Streater timstreater@redacted.invalid wrote:
In article 1koznr4.sxbt921me61qgN%dcohenspam@redacted.invalid, dcohenspam@redacted.invalid (Daniel Cohen) wrote:
Barry Margolin barmar@redacted.invalid wrote:
How does the -a option act differently from what the man page says? I just tried:
open -a TextEdit filename.docx
and the Word document was opened in TextEdit as desired. It's supposed to be like using the 'Open With' contextual menu in the Finder. The man page says "Specifies the application to use for opening the file", which seems to be a reasonable description of what that does.
Yes, that's fine, the manual explains what
open -a application file
does, but one has to have more experience than I have to realise that this also covers
open -a application
That was explained to me by David Empson in a thread related to this on the Apple Support Communities Mountain Lion section
You can also do such as:
open -a Safari 'http://www.example.com/'
which I have found very handy.
I usually just say
open http://www.example.com
Fine but I needed Safari to do it.
So did I.