I'm looking for a way to put a Mac to sleep from the command line.
I looked at pmset but it only seems to change the sleep scheduler. pmset also needs to be run as root. I'm just looking for a one-time command to put a Mac to sleep that a non-admin user can enter from the command line.
Failing that, an Automator action to sleep a Mac will do. But I can't find anything there either.
Any ideas?
me@redacted.invalid (Kir·ly) writes:
I'm looking for a way to put a Mac to sleep from the command line.
I looked at pmset but it only seems to change the sleep scheduler. pmset also needs to be run as root. I'm just looking for a one-time command to put a Mac to sleep that a non-admin user can enter from the command line.
Failing that, an Automator action to sleep a Mac will do. But I can't find anything there either.
This works for me
osascript -e 'tell application "System Events" to sleep'
Kir·ly me@redacted.invalid wrote:
I'm looking for a way to put a Mac to sleep from the command line.
I looked at pmset but it only seems to change the sleep scheduler. pmset also needs to be run as root. I'm just looking for a one-time command to put a Mac to sleep that a non-admin user can enter from the command line.
Failing that, an Automator action to sleep a Mac will do. But I can't find anything there either.
Any ideas?
Google "command line sleep mac os x".
m.
Doug Anderson ethelthelogremovethis@redacted.invalid wrote:
osascript -e 'tell application "System Events" to sleep'
Perfect. That does just what I need. Thanks!
matt neuburg matt@redacted.invalid wrote:
Google "command line sleep mac os x".
Oh, I tried that first before posting. Couldn't find anything relevant, except for the first hit, but the first hit was far too complicated and cumbersome for me.
Kir·ly me@redacted.invalid wrote:
matt neuburg matt@redacted.invalid wrote:
Google "command line sleep mac os x".
Oh, I tried that first before posting. Couldn't find anything relevant, except for the first hit, but the first hit was far too complicated and cumbersome for me.
Hmm. The first hit OMM gave exactly the same solution that you said was "perfect" in the other part of this thread. m.
On Sep 17, 6:30 pm, m...@redacted.invalid (matt neuburg) wrote:
Hmm. The first hit OMM gave exactly the same solution that you said was "perfect" in the other part of this thread. m.
Do you mean this page?
http://www.majid.info/mylos/weblog/2003/12/05-1.html
No terminal command that I can see on that page. All I can see is a shell script to either build yourself or a binary to download. Many c.s.m.s. readers might be able to translate a shell script into a terminal command. But not me.
-- K.
Lang may your lum reek.
In article 1190141843.660175.202460@redacted.invalid, Kir°ly ggrandish@redacted.invalid wrote:
http://www.majid.info/mylos/weblog/2003/12/05-1.html
No terminal command that I can see on that page. All I can see is a shell script to either build yourself or a binary to download. Many c.s.m.s. readers might be able to translate a shell script into a terminal command. But not me.
No, hello in there: you asked for a command-line command to put your computer to sleep. Apple haven't included one that we can find. The binaries you download from that page are in fact command-line commands to put your computer to sleep; the source code is included, incredibly well-documented, and you can compile it yourself; or you can just install the executables in whatever bin place you want.
It doesn't have to come from Apple to be useful. Things like ffmpeg or rsync or Apache 2 come to mind.
Also, the shell script on that page is about as simple as it gets:
#!/bin/bash osascript << EOT tell application "System Events" sleep end EOT
I mean, really. Copy it into a text file called slp, save it without an extension, make it executable (chmod +x slp), run it, see what happens. (I haven't tried it yet, the computer's doing some stuff I need to finish, but I can bet it all works).
In article 46f0326e$0$26204$c3e8da3@redacted.invalid, Warren Oates warren.oates@redacted.invalid wrote:
In article 1190141843.660175.202460@redacted.invalid, Kir°ly ggrandish@redacted.invalid wrote:
http://www.majid.info/mylos/weblog/2003/12/05-1.html
No terminal command that I can see on that page. All I can see is a shell script to either build yourself or a binary to download. Many c.s.m.s. readers might be able to translate a shell script into a terminal command. But not me.
No, hello in there: you asked for a command-line command to put your computer to sleep. Apple haven't included one that we can find. The binaries you download from that page are in fact command-line commands to put your computer to sleep; the source code is included, incredibly well-documented, and you can compile it yourself; or you can just install the executables in whatever bin place you want.
It doesn't have to come from Apple to be useful. Things like ffmpeg or rsync or Apache 2 come to mind.
Also, the shell script on that page is about as simple as it gets:
#!/bin/bash osascript << EOT tell application "System Events" sleep end EOT
I mean, really. Copy it into a text file called slp, save it without an extension, make it executable (chmod +x slp), run it, see what happens. (I haven't tried it yet, the computer's doing some stuff I need to finish, but I can bet it all works).
Being sure that you use unix end-of-line characters (linefeed or 0x0a) and not Mac end-od-line characters (return or 0x0d).
In article tomstiller-22769E.18465518092007@redacted.invalid, Tom Stiller tomstiller@redacted.invalid wrote:
I mean, really. Copy it into a text file called slp, save it without an extension, make it executable (chmod +x slp), run it, see what happens. (I haven't tried it yet, the computer's doing some stuff I need to finish, but I can bet it all works).
Being sure that you use unix end-of-line characters (linefeed or 0x0a) and not Mac end-od-line characters (return or 0x0d).
Hmm. I'm assuming he's working on a Mac, whose apps will take care of all that. I've never had "local" problems with that kind of thing. I should say, use a text editor (like emacs), not a word processor, I guess.
In article 46f05923$0$550$c3e8da3@redacted.invalid, Warren Oates warren.oates@redacted.invalid wrote:
In article tomstiller-22769E.18465518092007@redacted.invalid, Tom Stiller tomstiller@redacted.invalid wrote:
I mean, really. Copy it into a text file called slp, save it without an extension, make it executable (chmod +x slp), run it, see what happens. (I haven't tried it yet, the computer's doing some stuff I need to finish, but I can bet it all works).
Being sure that you use unix end-of-line characters (linefeed or 0x0a) and not Mac end-od-line characters (return or 0x0d).
Hmm. I'm assuming he's working on a Mac, whose apps will take care of all that. I've never had "local" problems with that kind of thing. I should say, use a text editor (like emacs), not a word processor, I guess.
Mac or not, as far as I know, none of the shells recognize as end-of-line. I use TextWrangler exclusively for text editing and having fallen into that trap too many times, have set its default to be the unix style EOL.
In article tomstiller-417DDB.21222518092007@redacted.invalid, Tom Stiller tomstiller@redacted.invalid wrote:
Mac or not, as far as I know, none of the shells recognize as end-of-line. I use TextWrangler exclusively for text editing and having fallen into that trap too many times, have set its default to be the unix style EOL.
Well, I dunno, I copied that script with my mouse from the website, pasted it straight into Emacs, saved it, made it executable, and it puts the computer to sleep right smartly. I haven't tried the C stuff yet. I do that kind of thing a lot.
I recommend Emacs.
Warren Oates warren.oates@redacted.invalid wrote:
Well, I dunno, I copied that script with my mouse from the website, pasted it straight into Emacs, saved it, made it executable, and it puts the computer to sleep right smartly. I haven't tried the C stuff yet. I do that kind of thing a lot.
So you do that kind of thing a lot. I'm not surprised. I don't, which is why the instructions on the page linked previously are too confusing for me.
"Read script, open text editor, paste in script, save, chmod +x, save in convenient location, there might be problems with carriage returns, so be sure to use emacs and not TextEdit, yada yada...""
Not everyone who posts to this newsgroup is a UNIX geek who automatically knows to do all of that stuff. None of it is explained on the page you directed me to. Doug Anderson's answer was exactly what I had asked for.
In article 1IbIi.3523$nO3.2194@redacted.invalid, me@redacted.invalid (Kir°ly) wrote:
Not everyone who posts to this newsgroup is a UNIX geek who automatically knows to do all of that stuff. None of it is explained on the page you directed me to. Doug Anderson's answer was exactly what I had asked for.
Can I ask you why you want a command-line command to sleep your Mac if you don't know how to use the command line tools that you have at your disposal?
Warren Oates warren.oates@redacted.invalid writes:
In article 1IbIi.3523$nO3.2194@redacted.invalid, me@redacted.invalid (Kir°ly) wrote:
Not everyone who posts to this newsgroup is a UNIX geek who automatically knows to do all of that stuff. None of it is explained on the page you directed me to. Doug Anderson's answer was exactly what I had asked for.
Can I ask you why you want a command-line command to sleep your Mac if you don't know how to use the command line tools that you have at your disposal?
I can't answer for him.
Sometimes at home, I'll be on my laptop, and realize that I think one of our desktops is on. It is easier for me to ssh into it, and put it to sleep that way than to go downstairs, put it to sleep with the mouse or the switch, and go back upstairs. Just lazy.
Also, sometimes I will be at home, and will need to shutdown my desktop at work. Similar: log in via ssh, run shutdown -h now.
(Now if only I could turn on my machine at work from home too!)
Making a shell script is fine too, but if you don't already know how to use emacs (or something similar - textedit usually won't do as it leaves too much non-text in) and don't know how to use chmod, you may still want to do the things I described above. And since you can, why not?
Warren Oates warren.oates@redacted.invalid wrote:
Can I ask you why you want a command-line command to sleep your Mac if you don't know how to use the command line tools that you have at your disposal?
I had been looking to program a keyboard shortcut that would first switch to the login window and then sleep the Mac (I had been getting tired of using the mouse for that.) I found Xkeys that allows one to program an F key to open an app. I figured that if I could write an app to do what I wanted then I would have my keyboard shortcut.
I'm sure many of you know how to write apps with applescript or with C or to compile shell scripts. But the only way I know how to write an app is with Automator. I couldn't find any built-in Automator actions for the login window switch or sleep, but I did find the action to run a Terminal command. Google found me a terminal command to switch to the login window, but I was coming up dry for a command to sleep the Mac. Hence me asking in here.
Kudos to Mr. Anderson for answering my question. My Mac now switches to the login window and goes to sleep when I press F13.
Did I really need to justify myself?
Kir·ly wrote:
Warren Oates warren.oates@redacted.invalid wrote:
Can I ask you why you want a command-line command to sleep your Mac if you don't know how to use the command line tools that you have at your disposal?
I had been looking to program a keyboard shortcut that would first switch to the login window and then sleep the Mac (I had been getting tired of using the mouse for that.) I found Xkeys that allows one to program an F key to open an app. I figured that if I could write an app to do what I wanted then I would have my keyboard shortcut.
I'm sure many of you know how to write apps with applescript or with C or to compile shell scripts. But the only way I know how to write an app is with Automator. I couldn't find any built-in Automator actions for the login window switch or sleep, but I did find the action to run a Terminal command. Google found me a terminal command to switch to the login window, but I was coming up dry for a command to sleep the Mac. Hence me asking in here.
Kudos to Mr. Anderson for answering my question. My Mac now switches to the login window and goes to sleep when I press F13.
Did I really need to justify myself?
Of course, this is Usenet.
Are you bringing up the login window before sleeping so that someone else can log in if they wake up your Mac?
Greg
Kir·ly me@redacted.invalid wrote:
I'm sure many of you know how to write apps with applescript or with C or to compile shell scripts. But the only way I know how to write an app is with Automator. I couldn't find any built-in Automator actions for the login window switch or sleep, but I did find the action to run a Terminal command. Google found me a terminal command to switch to the login window, but I was coming up dry for a command to sleep the Mac. Hence me asking in here.
I'm not quite following. There is an Automator action for running an AppleScript. You know the AppleScript for telling the Mac to sleep. So why are you going thru the Terminal?
Of course you could just use LaunchBar, which has a built-in sleep command and is useful for a lot of other stuff besides.
m.
In article tbbqbyzk9l.fsf@redacted.invalid, Doug Anderson ethelthelogremovethis@redacted.invalid wrote:
Making a shell script is fine too, but if you don't already know how to use emacs (or something similar - textedit usually won't do as it leaves too much non-text in) and don't know how to use chmod, you may still want to do the things I described above. And since you can, why not?
I just did it with TextEdit -- it worked just fine. Paste it, save it (to the Desktop if you want) without an extension, away you go. You don't even have to make it executable, you can run it
[~]$ sh Desktop/slp
and nightie-night Mac. I figured he wanted a way to put a remote machine to sleep. I don't know about waking it up remotely.
In article AxcIi.3525$nO3.1600@redacted.invalid, me@redacted.invalid (Kir°ly) wrote:
Kudos to Mr. Anderson for answering my question. My Mac now switches to the login window and goes to sleep when I press F13.
Did I really need to justify myself?
Absolutely not. I thought I had phrased my query as to your motives rather politely, at least for me. The point is, that script is about as simple a script as you'll ever see, and a good starting point for some interesting experimentation.
But, no, no one ever has to justify anything to me, not even that OJ Simpson N-word. Feel free to ignore me, my mother always did ...
G.T. getnews1@redacted.invalid wrote:
Are you bringing up the login window before sleeping so that someone else can log in if they wake up your Mac?
That's one reason. But the bigger reason is that I have my accounts set to require a password on wake. Problem is, when the Mac auto wakes at 4:00am to run my automated Retrospect backup, and nobody is around to enter the password, the Mac goes back to sleep after 30 seconds and the backup does not run. The workaround is to switch to the login window before sleeping, and then when the Mac auto-wakes it stays awake.
matt neuburg matt@redacted.invalid wrote:
I'm not quite following. There is an Automator action for running an AppleScript. You know the AppleScript for telling the Mac to sleep.
I do? That's news to me. What is it? Was it referenced somewhere in this thread?
In article cGeIi.72082$bO6.6509@redacted.invalid, me@redacted.invalid (Kir·ly) wrote:
Are you bringing up the login window before sleeping so that someone else can log in if they wake up your Mac?
That's one reason. But the bigger reason is that I have my accounts set to require a password on wake. Problem is, when the Mac auto wakes at 4:00am to run my automated Retrospect backup, and nobody is around to enter the password, the Mac goes back to sleep after 30 seconds and the backup does not run. The workaround is to switch to the login window before sleeping, and then when the Mac auto-wakes it stays awake.
Will the backup still run if the login window is the front window?
me@redacted.invalid (Kir·ly) writes:
matt neuburg matt@redacted.invalid wrote:
I'm not quite following. There is an Automator action for running an AppleScript. You know the AppleScript for telling the Mac to sleep.
I do? That's news to me. What is it? Was it referenced somewhere in this thread?
Yes, the command line command I suggested is actually a command to run a bit of applescript.
Of course you have no reason to recognize it as such!
(type
man osascript
at a command line to learn more about this.)
Michelle Steiner michelle@redacted.invalid wrote:
Will the backup still run if the login window is the front window?
Yes it does! It even runs if all user accounts are logged out. Show me another backup app that can do that.
That's why Retrospect is such a powerful program. Terrible user interface and a real PITA to learn, but unmatched features and power for the user with enough patience and hair to pull out. :)
I've suggested to the Shirt-Pocket folks to allow SuperDuper scheduled backups to run when the login window is in front. They said it's an improvement they'll consider adding in a future version.
Doug Anderson ethelthelogremovethis@redacted.invalid wrote:
Yes, the command line command I suggested is actually a command to run a bit of applescript.
Aha! I didn't know that.
Of course you have no reason to recognize it as such!
...which of course I didn't, not being well versed in applescript. Thanks again.
""Kir·ly"" me@redacted.invalid wrote in message news:HafIi.72086$bO6.36879@redacted.invalid
Michelle Steiner michelle@redacted.invalid wrote:
Will the backup still run if the login window is the front window?
Yes it does! It even runs if all user accounts are logged out. Show me another backup app that can do that.
That's why Retrospect is such a powerful program. Terrible user interface and a real PITA to learn, but unmatched features and power for the user with enough patience and hair to pull out. :)
I've suggested to the Shirt-Pocket folks to allow SuperDuper scheduled backups to run when the login window is in front. They said it's an improvement they'll consider adding in a future version.
If they had a command line version then you wouldn't have to jump through these hoops.
Greg
In article 02320794$0$28426$c3e8da3@redacted.invalid, Warren Oates warren.oates@redacted.invalid wrote:
I don't know about waking it up remotely.
How about "System Preferences" "Energy Saver" "Options" enable "Wake for Ethernet administrator access".
Then you can use magic packets http://en.wikipedia.org/wiki/Wake-on-LAN
How you get those through to your work machine is an exercise for the reader (with us it's VPN into site then multicast the packet to our subnet)!
Kind regards,
Dave
On 2007-09-19 14:57:27 -0500, me@redacted.invalid (Kir·ly) said:
Michelle Steiner michelle@redacted.invalid wrote:
Will the backup still run if the login window is the front window?
Yes it does! It even runs if all user accounts are logged out. Show me another backup app that can do that.
That's why Retrospect is such a powerful program. Terrible user interface and a real PITA to learn, but unmatched features and power for the user with enough patience and hair to pull out. :)
Technically, what Retrospect does (running behind the login window) is somewhat of a security risk. It's bad behavior, so I wouldn't exactly commend them for this.
Jolly Roger wbyylebtre@redacted.invalid writes:
Technically, what Retrospect does (running behind the login window) is somewhat of a security risk. It's bad behavior, so I wouldn't exactly commend them for this.
I don't know what you mean by "Technically". Does it use some trick to do so which makes it more of a security risk than any daemon?
It seems to me to be a major flaw in Superduper that its scheduled run will not happen unless the user in whose account it is run is logged in. This means that if she happens to log out before going to bed - or if I'm the last to use her computer and don't log her back in - then the backup doesn't run.
On 2007-09-20 12:21:09 -0500, William Mitchell mitchell@redacted.invalid said:
Jolly Roger wbyylebtre@redacted.invalid writes:
Technically, what Retrospect does (running behind the login window) is somewhat of a security risk. It's bad behavior, so I wouldn't exactly commend them for this.
I don't know what you mean by "Technically".
I meant "technically speaking".
Does it use some trick to do so which makes it more of a security risk than any daemon?
No tricks involved. Retrospect runs as root, which isn't a bad thing in itself, until you realize it does not check to see if anyone is logged in before launching its user interface. Any root application running behind the login window is a security hole. Anyone at the console may access Retrospect in this state - even persons without user accounts on the machine! It's a bad thing. If Retrospect ran without the UI when nobody was logged in, then the security hole wouldn't be there.
It seems to me to be a major flaw in Superduper that its scheduled run will not happen unless the user in whose account it is run is logged in. This means that if she happens to log out before going to bed - or if I'm the last to use her computer and don't log her back in - then the backup doesn't run.
That's not good either, but I certainly hope I never see SuperDuper display a UI as root behind a login window.
Jolly Roger wbyylebtre@redacted.invalid writes:
On 2007-09-20 12:21:09 -0500, William Mitchell mitchell@redacted.invalid said:
Jolly Roger wbyylebtre@redacted.invalid writes:
No tricks involved. Retrospect runs as root, which isn't a bad thing in itself,
A necessary thing, in fact, if you want to backup system files!
until you realize it does not check to see if anyone is logged in before launching its user interface. Any root application running behind the login window is a security hole. Anyone at the console may access Retrospect in this state - even persons without user accounts on the machine! It's a bad thing. If Retrospect ran without the UI when nobody was logged in, then the security hole wouldn't be there.
That does certainly look like a security hole, though I confess I still don't understand why it is only "technically" so.
It seems to me that any serious general backup system would have an engine to do the actual backup which is capable of running without a UI, and which would do so for scheduled backups.
In article D.P.C.Sankey-A1B728.15063020092007@redacted.invalid, David Sankey D.P.C.Sankey@redacted.invalid wrote:
How you get those through to your work machine is an exercise for the reader (with us it's VPN into site then multicast the packet to our subnet)!
Hmm. I'll take a look at that wicked-pedia site; I want something less complicated than VPN.
On Sep 20, 11:54 am, Jolly Roger wbyyleb...@redacted.invalid wrote:
Retrospect runs as root, which isn't a bad thing in itself, until you realize it does not check to see if anyone is logged in before launching its user interface. Any root application running behind the login window is a security hole. Anyone at the console may access Retrospect in this state - even persons without user accounts on the machine! It's a bad thing. If Retrospect ran without the UI when nobody was logged in, then the security hole wouldn't be there.
It's true that Retrospect runs as root, and runs visibly around and behind the login window when the login window is displayed, even when no users are logged in. But it's not true that anyone at the console can access Retrospect in that state. When I try I am prompted to enter an admin username and password to change anything.
That's not good either, but I certainly hope I never see SuperDuper display a UI as root behind a login window.
It's okay with me, but only if, like Retrospect, it asks for admin authentication when somebody tries to interrupt or change it.
-- K.
Lang may your lum reek.
On 2007-09-20 17:57:01 -0500, Kir·ly ggrandish@redacted.invalid said:
On Sep 20, 11:54 am, Jolly Roger wbyyleb...@redacted.invalid wrote:
Retrospect runs as root, which isn't a bad thing in itself, until you realize it does not check to see if anyone is logged in before launching its user interface. Any root application running behind the login window is a security hole. Anyone at the console may access Retrospect in this state - even persons without user accounts on the machine! It's a bad thing. If Retrospect ran without the UI when nobody was logged in, then the security hole wouldn't be there.
It's true that Retrospect runs as root, and runs visibly around and behind the login window when the login window is displayed, even when no users are logged in. But it's not true that anyone at the console can access Retrospect in that state. When I try I am prompted to enter an admin username and password to change anything.
Well that's an optional feature of Retrospect that is not enabled by default. Also, it does not prevent someone from sending AppleEvents with buffer overflows, and other nasty things to the application. There is a plethora of attack vectors for any application running as root. Running any GUI application as root at the console login screen is a bad idea.
That's not good either, but I certainly hope I never see SuperDuper display a UI as root behind a login window.
It's okay with me, but only if, like Retrospect, it asks for admin authentication when somebody tries to interrupt or change it.
It's not okay with me - too many potential attack vectors.
Jolly Roger jollyroger@redacted.invalid wrote:
Well that's an optional feature of Retrospect that is not enabled by default.
That's not my experience here. Retrospect has always prompted for admin authentication when attempting to meddle with it while the login window is displayed, right out of the box. Right now, my "always require authentication" security preference is off, yet it still prompts for authentication while running as root behind the login window.
it does not prevent someone from sending AppleEvents with buffer overflows, and other nasty things to the application. There is a plethora of attack vectors for any application running as root. Running any GUI application as root at the console login screen is a bad idea.
Can you explain more? I don't see the difference between a root task running invisibly as a cron job, and one running visibly behind the login window but requiring admin authentication to meddle with.