sleep from terminal

1. johnny bobby bee - 1 January 2006

   I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.

   Cheers.

   NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

2. Hans Aberg - 1 January 2006

   Probably not, as sleep depends on code external to the UNIX kernel.

   Hans Aberg

3. ZnU - 1 January 2006

   AppleScript is your friend:

   osascript -e 'tell application "Finder" to sleep'

   This make not work if the user you're logged in as isn't logged into the GUI.

   "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

4. Andre Berger - 1 January 2006

   Darwinports has got a sleepnow package.

   -Andre

5. johnny bobby bee - 1 January 2006

   ZnU wrote:

   AppleScript is your friend:

   osascript -e 'tell application "Finder" to sleep'

   Wacky applescript, it works; cheers.

   NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

6. johnny bobby bee - 1 January 2006

   Hans Aberg wrote:

   Probably not, as sleep depends on code external to the UNIX kernel.

   OS X doesn't really use a traditional UNIX kernel, does it? Panther has replaced init (and others?) with launchd. So, you'd think there could be a built-in apple command to initiate sleep. I'm no apple scripter, but as we see below it can be done with an apple script from terminal. Just thought there would be something like apm or acpid.

   NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

7. Hans Aberg - 1 January 2006

   Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel. Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

   Hans Aberg

8. Hans Aberg - 2 January 2006

   Looking at 'man launchd' and 'man init', launchd is used as the root process with PID = 1, and at the end of the boot process, it launches init, which would be the normal root process under BSD. The UNIX kernel (Mach under Mac OS X), does however itself not launch any programs or processes: only a process can launch another process. The kernel just keeps track of these processes, scheduling them, making sure they do not do anything illegal. So all processes end up on a parent-child tree, depending how processes (parents) launch other processes (children).

   Then the UNIX kernel cannot go to sleep by itself. So Apple must have installed some other code, first called at boot. Probably launchd links the UNIX kernel to this other code at boot, though I do not see exactly how. But the result is not only the ability to go to sleep, but the inability to handle certain code, kernel panics.

   Hans Aberg

9. Daniel Cohen - 2 January 2006

   Not really wacky. the 'tell ...' is just a straighforward AppleScript,

   osacript is a way of running AppleScripts in the shell,

   and the flag -e says that the script to run is the bit in quotes. If you had saved a script, as scriptname then

   osascript fullpathtoscriptname

   would run the script.

   Send e-mail to the Reply-To address;
   mail to the From address is never read

10. johnny bobby bee - 2 January 2006

    Daniel Cohen wrote:

    Not really wacky. the 'tell ...' is just a straighforward AppleScript,

    and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.

    NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

11. L - 2 January 2006

    That's Applescript's syntax:

    Tell application.app
    do this, that, and everything
    end tell

12. ZnU - 2 January 2006

    Well, sort of. The OS X kernel is actually an odd combination of Mach code and kernel code borrowed from various BSD systems.

    Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

    But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

13. Hans Aberg - 2 January 2006

    Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX kernel extensions, as it affects reliability, for example.

    The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.

    For Mac OS X, it seems that one has added a mini-OS, by which the FreeBSD and its Mach kernel run within.

    But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

    The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself. Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

    Hans Aberg

14. Hans Aberg - 3 January 2006

    Previously, ZnU wrote:

    Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

    One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

    Hans Aberg

15. Daniel Cohen - 3 January 2006

    Come to think of it, my version of the instructions was

    tell "System Events" to sleep

    That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.

    The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.

    Send e-mail to the Reply-To address;
    mail to the From address is never read

16. Dave Seaman - 3 January 2006

    No, 'sleep' is a menu item in the Apple Menu, which is shared by all applications.

    Dave Seaman
    U.S. Court of Appeals to review three issues
    concerning case of Mumia Abu-Jamal.
    <http://www.mumia2000.org/>

17. ZnU - 3 January 2006

    Huh? *No* code executes while the computer is sleeping. The CPU isn't even powered. And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

18. ZnU - 3 January 2006

    There *is* nothing in OS X which occurs outside of the *nix environment.

    Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

    Once again, there is no separate UNIX environment in OS X. OS X is a *nix operating system. All the Mac-like stuff runs *within* this environment.

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

19. Hans Aberg - 3 January 2006

    It sounds logical. But there has something that brings it back to life. An interrupt of some kind.

    And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

    It can take minutes before the kernel is loading, though.

    Hans Aberg

20. Hans Aberg - 3 January 2006

    Previously, ZnU wrote:

    There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs *on top* of this kernel.

    So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads). So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

    Hans Aberg

21. ZnU - 3 January 2006

    Sure, but it's not part of the operating system, or any other software. It's a hardware feature.

    Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

    momentum:/ znu$ ls -l mach_kernel
    -rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

22. ZnU - 3 January 2006

    That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.

    So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

    Mach *is* a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.

    The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.

    There's a decent high-level overview at:

    http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

23. Steven Fisher - 3 January 2006

    Previously, ZnU wrote:

    Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

    momentum:/ znu$ ls -l mach_kernel
    -rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

    Yeah, this confused me for a while, too. I think he is thinking of some of the maintenance tasks early in startup.

    Steven Fisher; sdfisher@spamcop.net

24. Matthew Russotto - 3 January 2006

    The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.

    There's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one.

25. Hans Aberg - 3 January 2006

    If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.

    Hans Aberg

26. Hans Aberg - 3 January 2006

    The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.

    There's a decent high-level overview at:

    http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

    Thanks for the link. But does not seem to address the kernel structure issue.

    Hans Aberg

27. Hans Aberg - 3 January 2006

    Thank you. So it is the PMU one should get rid of. :-)

    Hans Aberg

28. ZnU - 4 January 2006

    When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

29. ZnU - 4 January 2006

    Try:
    http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

30. Hans Aberg - 4 January 2006

    Right, but they should load early on.

    Hans Aberg

31. Hans Aberg - 4 January 2006

    Previously, ZnU wrote:

    http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

    That is better. As for kernel vs. microkernel, there is probably a considerable flux as how to term what is what; see:
    http://en.wikipedia.org/wiki/Kernel_%28computer_science%29 http://en.wikipedia.org/wiki/Microkernel

    Hans Aberg

32. ZnU - 4 January 2006

    Sure, daemons will typically load during the bit of the boot sequence where the progress bar is displayed. You can hold down command-v (which switches to verbose boot mode) to see some of this.

    "Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005