Re: [Tutor] Running a script in the background

[eryksun]

On Mon, Sep 3, 2012 at 10:21 PM, Dwight Hutto  wrote:
> What's wrong with:
>
> But each OS(BIOS handler) has a way of providing/accepting instructions to
> the processor, which is constantly procedural. This has to have a terminal
> at some point.

What do you mean by 'terminal' in this context? A terminal is a device
(possibly virtual) for entering data and displaying output from a
computer.

cron isn't scheduling active processes/threads like the kernel does.
Every minute, it checks a job table and possibly starts one or more
programs. This is an efficient way to schedule a large number of
programs to run at various times throughout the day, week, and month.
Otherwise all of these programs would need to have at least a stub
that runs as a daemon, wasting memory and CPU resources needlessly.

Scheduling processes is an entirely different domain. In a preemptive
multitasking system, it's up to the kernel to schedule access to the
CPU. Each process (or thread on some systems) is assigned a quantum of
ticks. The ticks are based on a hardware timer. Periodically (e.g. 10
milliseconds) this timer triggers a hardware interrupt that enables
the kernel to preempt the current thread. The kernel schedules the
next (possibly the same) process to run, based on a priority scheme,
out of the pool of ready processes.

Preempting a running process requires a context switch, i.e. the
process control block (e.g. PID, priority, execution state such as
running/ready/waiting, CPU number/registers/flags, virtual memory,
signal handlers, I/O, credentials, accounting, etc) has to be saved on
the current stack. Then the PCB of the next process is loaded; the CPU
state is restored; and execution resumes seamlessly.

Here's the task_struct used by the Linux scheduler (lines 1235-1593):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/linux/sched.h#l1235

> What is meant by behind a console, and running without a console, just a
> window system, and a file set that deals with instructions/errors based on
> BIOS input/output?

Windows NT typically boots without a console. It doesn't have virtual
terminals, but you can run console programs in a Win32 console managed
by the Client/Server Runtime Subsystem (csrss.exe)

In contrast, Linux boots in console mode. Typically it maps the
"console" (boot parameter) to the current virtual terminal (i.e.
/dev/tty0), but it could also be a dumb terminal or modem. It creates
several virtual terminals depending on the system configuration.
Debian has tty's 1-63 and runs getty on tty 1-6 to allow text-mode
logins and an Xorg display manager (e.g. lightdm) on tty7 for logging
in to a graphical desktop environment (e.g. xfce4).
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Alan Gauld]

On 04/09/12 01:26, Dwight Hutto wrote:


But each OS(BIOS handler) has a way of providing/accepting instructions
to the processor, which is constantly procedural. This has to have a
terminal at some point.


No it doesn't. Most OS do not run in a 'procedural' way (by which I 
assume you mean sequential?) Most are event driven and that often at the 
hardware level. The processor has an interrupt mechanism which causes a 
section of code to run. The section chosen is determined by the 
interrupt number and results in a jump to a predefined address.

The interrupts are driven by hardware events with no software control.
Some interrupts are pre-emptive - they will stop any current processing 
and take control, others will wait for current processing to finish.
The processor will also have a software interrupt mechanism which does 
the same thing but is driven by an INT call in the software.


Operating systems from CP/M and DOS onwards are driven by interrupts
at the kernel level they do not sit in some kind of giant event loop 
looking for things to process.



What is meant by behind a console, and running without a console, just a
window system, and a file set that deals with instructions/errors based
on BIOS input/output?


Again no, a terminal is an I/O mechanism. It reads input and displays 
output. The terminal does not process the commands it passes those to 
the program running inside it. Even the shell is not part of the 
Terminal, it just runs inside. And daemon programs do not use a terminal 
at all.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

On Mon, Sep 3, 2012 at 9:56 PM, Steven D'Aprano  wrote:

> On 04/09/12 10:26, Dwight Hutto wrote:
>
>  On *nix there is a cron daemon that runs in the background.
>>> but one job running in the background controlling dozens(?) of
>>>
>>> others is way more efficient than dozens of programs all running idle in
>>> the background and periodically springing into action.
>>>
>>>
>> But each OS(BIOS handler) has a way of providing/accepting instructions to
>> the processor, which is constantly procedural. This has to have a terminal
>> at some point.
>>
>> What is meant by behind a console, and running without a console, just a
>> window system, and a file set that deals with instructions/errors based on
>> BIOS input/output?
>>
>
>
> On Mon, Sep 3, 2012 at 9:56 PM, Steven D'Apran
>
> Best regards,
> o  wrote:
>
>> On 04/09/12 10:26, Dwight Hutto wrote:
>>
>>  On *nix there is a cron daemon that runs in the background.
 but one job running in the background controlling dozens(?) of

 others is way more efficient than dozens of programs all running idle in
 the background and periodically springing into action.


>>> But each OS(BIOS handler) has a way of providing/accepting instructions
>>> to
>>> the processor, which is constantly procedural. This has to have a
>>> terminal
>>> at some point.
>>>
>>> What is meant by behind a console, and running without a console, just a
>>> window system, and a file set that deals with instructions/errors based
>>> on
>>> BIOS input/output?
>>>
>>
>> I'm afraid these sentences sound like gobbledygook to me. No offense
>> Dwight,
>> but it sounds like you're randomly inserting "computer terms" into
>> sentences
>> with no meaning.
>>
>> Which one's. If yuou could, please reply on a line by line, because some
of what you listed above isn't mine.

What's wrong with:



But each OS(BIOS handler) has a way of providing/accepting instructions to
the processor, which is constantly procedural. This has to have a terminal
at some point.

What is meant by behind a console, and running without a console, just a
window system, and a file set that deals with instructions/errors based on
BIOS input/output?

I'll add Intel/AMD to the instructions secton.

 The gobbledy gook, might be a little smeared on your face...Want a
rag?...Steven

By the way, you can call me David...buddy.


The only part that actually makes sense to me is:
>>
>>
>> "This has to have a terminal at some point."
>>
>> but that is not true. The fact that cron runs without a tty (a terminal)
>> is
>> proof of that.
>>
>>
>>
>> --
>> Steven
>>
>> ___
>> Tutor maillist  -  Tutor@python.org
>> To unsubscribe or change subscription options:
>> http://mail.python.org/mailman/listinfo/tutor
>>
>
> I'm afraid these sentences sound like gobbledygook to me. No offense
> Dwight,
> but it sounds like you're randomly inserting "computer terms" into
> sentences
> with no meaning.
>
> The only part that actually makes sense to me is:
>
>
> "This has to have a terminal at some point."
>
> but that is not true. The fact that cron runs without a tty (a terminal) is
> proof of that.
>
>
>
> --
> Steven
>
> __**_
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Steven D'Aprano]

On 04/09/12 10:26, Dwight Hutto wrote:


On *nix there is a cron daemon that runs in the background.
but one job running in the background controlling dozens(?) of
others is way more efficient than dozens of programs all running idle in
the background and periodically springing into action.



But each OS(BIOS handler) has a way of providing/accepting instructions to
the processor, which is constantly procedural. This has to have a terminal
at some point.

What is meant by behind a console, and running without a console, just a
window system, and a file set that deals with instructions/errors based on
BIOS input/output?


I'm afraid these sentences sound like gobbledygook to me. No offense Dwight,
but it sounds like you're randomly inserting "computer terms" into sentences
with no meaning.

The only part that actually makes sense to me is:

"This has to have a terminal at some point."

but that is not true. The fact that cron runs without a tty (a terminal) is
proof of that.



--
Steven
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

On Mon, Sep 3, 2012 at 7:57 PM, Alan Gauld wrote:

> On 03/09/12 22:46, Dwight Hutto wrote:
>
>  But a script is always running in the background of the OS main console
>> of the upfront GUI app users usually see, correct?
>>
>
> Not every OS has a main console behind the GUI, but in the case of *nix
> its true.
>
> On *nix there is a cron daemon that runs in the background.
> but one job running in the background controllingfat boy slim dozens(?) of
> others is way more efficient than dozens of programs all running idle in
> the background and periodically springing into action.
>

But each OS(BIOS handler) has a way of providing/accepting instructions to
the processor, which is constantly procedural. This has to have a terminal
at some point.

What is meant by behind a console, and running without a console, just a
window system, and a file set that deals with instructions/errors based on
BIOS input/output?


-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Alan Gauld]

On 03/09/12 22:46, Dwight Hutto wrote:


But a script is always running in the background of the OS main console
of the upfront GUI app users usually see, correct?


Not every OS has a main console behind the GUI, but in the case of *nix 
its true.


On *nix there is a cron daemon that runs in the background.
but one job running in the background controlling dozens(?) of others is 
way more efficient than dozens of programs all running idle in the 
background and periodically springing into action.



back to a main script in OS runtime checking for processes to run, even
for other processes, for other processes, etc.


Ultimately it all goes back to the OS scheduler which constantly swaps 
processes in and out of run mode...


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

>
> Cron or another process that oversees cron has to continually run.
>

> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com*
>
>


-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

On Sun, Sep 2, 2012 at 9:03 PM, Steven D'Aprano  wrote:

> On Sun, Sep 02, 2012 at 03:14:53PM -0700, Ray Jones wrote:
> > This is only tangentially related to the thread. Someone mentioned that
> > so long as a script didn't require user input or output to the user, it
> > could run silently in the background. But is there a way for a Python
> > (2.7.3) script to determine whether it was called by the user or called
> > by something like cron or kalarm? That way user inputs could be used
> > when called by a user, but defaults could be used if run by a bot.
>
> The usual way to detect this is by checking whether or not there is a
> terminal available.
>
> os.isatty(sys.stdout.fileno())
>
> If the script is running directly in a console, isatty will return True;
> if it is running from cron, or via a pipe or similar, then it will
> return False.


But a script is always running in the background of the OS main console of
the upfront GUI app users usually see, correct?

Cron has to coninually run, or have another process that checks x number
per minute(hertz of the process) to see what is going on, so it all goes
back to a main script in OS runtime checking for processes to run, even for
other processes, for other processes, etc.

-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background (offshoot - sorry, OP)

[Ray Jones]

On 09/02/2012 06:03 PM, Steven D'Aprano wrote:
> On Sun, Sep 02, 2012 at 03:14:53PM -0700, Ray Jones wrote:
>> This is only tangentially related to the thread. Someone mentioned that
>> so long as a script didn't require user input or output to the user, it
>> could run silently in the background. But is there a way for a Python
>> (2.7.3) script to determine whether it was called by the user or called
>> by something like cron or kalarm? That way user inputs could be used
>> when called by a user, but defaults could be used if run by a bot.
> The usual way to detect this is by checking whether or not there is a 
> terminal available.
>
> os.isatty(sys.stdout.fileno())
>
> If the script is running directly in a console, isatty will return True; 
> if it is running from cron, or via a pipe or similar, then it will 
> return False.
Okay. Your solution works with cron - it does not work with kalarm
(KDE's system alarm). The only reason I'm using kalarm rather than cron
to begin with is that kalarm is TZ aware while anacron only looks at the
system TZ (i.e. with kalarm I can start each task based on its own
individual time zone).

I read that fcron is fully TZ aware, but when I tried to install it, it
wanted to automatically remove anacron and the entire kubuntu-desktop!

Now this definitely gets into the Linux side of things. I'll go hit the
Ubuntu forums and see what I can find.

Thanks, everyone.


Ray
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background (this time Cc'd to the list)

[eryksun]

On Sun, Sep 2, 2012 at 9:04 PM, William R. Wing (Bill Wing)  
wrote:
>
> Apple's mechanism for launching applications at login is picky
> about what it will accept as a legitimate application to add to
> the list.

Here's an Ask Different (Apple Stack Exchange) answer with a template
for a launchd plist:

http://apple.stackexchange.com/a/822

I don't use OS X, so I can't offer anymore held than that.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background (this time Cc'd to the list)

[William R. Wing (Bill Wing)]

On Sep 2, 2012, at 6:15 PM, Alan Gauld  wrote:

> On 02/09/12 21:30, William R. Wing (Bill Wing) wrote:
> 
>> My suggestion would be to take the script and run it through py2app,
>> which will turn it into a stand-alone application which can then
>> be added to your list of StartUp or LogIn applications.
> 
> Why not just create a one line shell script that starts the python program 
> and add that to the Startup? What value does using py2app add in this case?
> 
> -- 
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/

Apple's mechanism for launching applications at login is picky about what it 
will accept as a legitimate application to add to the list.  You could get 
there by creating an "AppleScript" that did the same thing.  AppleScripts can 
be saved as applications and an AppleScript can call a python script (I've 
actually done that, but it leaves you maintaining two bits of code, not just 
one).  To the best of my knowledge, there is no way you can convince the 
application-picker to accept a shell script (or a raw python script) as an 
application.  You can add it to the list, but at login, what happens is that 
the editor you used to create the script gets invoked with the script opened in 
it.

-Bill
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Steven D'Aprano]

On Sun, Sep 02, 2012 at 03:14:53PM -0700, Ray Jones wrote:
> This is only tangentially related to the thread. Someone mentioned that
> so long as a script didn't require user input or output to the user, it
> could run silently in the background. But is there a way for a Python
> (2.7.3) script to determine whether it was called by the user or called
> by something like cron or kalarm? That way user inputs could be used
> when called by a user, but defaults could be used if run by a bot.

The usual way to detect this is by checking whether or not there is a 
terminal available.

os.isatty(sys.stdout.fileno())

If the script is running directly in a console, isatty will return True; 
if it is running from cron, or via a pipe or similar, then it will 
return False.



-- 
Steven
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Ray Jones]

On 09/02/2012 03:30 PM, Alan Gauld wrote:
> On 02/09/12 23:14, Ray Jones wrote:
>> could run silently in the background. But is there a way for a Python
>> (2.7.3) script to determine whether it was called by the user or called
>> by something like cron or kalarm? That way user inputs could be used
>> when called by a user, but defaults could be used if run by a bot.
>
> Yes you can query the user via the os module.(getuid or getlogin for
> example)
>
>> Or is this more of a Linux question?
>
> The details are likely to be implementation dependant, differing even
> between local hosts since it depends on how the admin has set up the
> user for cron etc
>

Thanks. I'll add this to my to-learn list (It's frustrating to come up
with questions and answers faster than I can assimilate it all :-p)


Ray
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Alan Gauld]

On 02/09/12 23:14, Ray Jones wrote:

could run silently in the background. But is there a way for a Python
(2.7.3) script to determine whether it was called by the user or called
by something like cron or kalarm? That way user inputs could be used
when called by a user, but defaults could be used if run by a bot.


Yes you can query the user via the os module.(getuid or getlogin for 
example)



Or is this more of a Linux question?


The details are likely to be implementation dependant, differing even 
between local hosts since it depends on how the admin has set up the 
user for cron etc


hth
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Ray Jones]

This is only tangentially related to the thread. Someone mentioned that
so long as a script didn't require user input or output to the user, it
could run silently in the background. But is there a way for a Python
(2.7.3) script to determine whether it was called by the user or called
by something like cron or kalarm? That way user inputs could be used
when called by a user, but defaults could be used if run by a bot.

Or is this more of a Linux question?


Ray
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[William R. Wing (Bill Wing)]

On Sep 2, 2012, at 5:06 PM, Michael Lewis  wrote:

> 
> 
> Michael, I see you have several Windows answers, but it doesn't look as 
> though you found quite what you were hoping for on OSX.  My suggestion would 
> be to take the script and run it through py2app, which will turn it into a 
> stand-alone application which can then be added to your list of StartUp or 
> LogIn applications.  If you never request input or produce output, it will 
> quite happily run in the background with no window and no menu (although by 
> default there will be an icon in the dock).  At that point it is so much a 
> background application that the ONLY way you can quit it is via the Force 
> Quit dialog.   If you generate status or housekeeping print messages, they 
> will show up in ~/Library/Logfiles.  Py2app isn't particularly memory 
> efficient, even a minimal application tends to run close to 9-10 Mbytes, but 
> if it spends most of its time sleeping, it will use very little in the way of 
> system resources.
> 
> Good luck,
> Bill
> 
> Thanks, Bill. That is definitely more of what I am looking for and actually 
> found that through some googling.  What I am confused about now, is what's 
> really the difference between py2app and the python Build Applet? 
> -- 
> Michael J. Lewis

I've never played with Build Applet, only py2app, so this may be partially or 
totally bogus, but py2app uses a fairly elaborate "setup" script that allows 
you to specify things like a custom icon (if you want one) as well as specific 
libraries.  Build Applet, on the other hand, is a much simpler tool that takes 
a single source file, pulls in any "includes" it finds and builds a default.  
It might in fact be sufficient for your needs.

If you've downloaded the python from python.org, you will definitely find both 
the Build Applet and PythonLauncher in a PythonXX folder in your Applications 
folder.

Good luck,
Bill


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Michael Lewis]

>
>
>
> Michael, I see you have several Windows answers, but it doesn't look as
> though you found quite what you were hoping for on OSX.  My suggestion
> would be to take the script and run it through py2app, which will turn it
> into a stand-alone application which can then be added to your list of
> StartUp or LogIn applications.  If you never request input or produce
> output, it will quite happily run in the background with no window and no
> menu (although by default there will be an icon in the dock).  At that
> point it is so much a background application that the ONLY way you can quit
> it is via the Force Quit dialog.   If you generate status or housekeeping
> print messages, they will show up in ~/Library/Logfiles.  Py2app isn't
> particularly memory efficient, even a minimal application tends to run
> close to 9-10 Mbytes, but if it spends most of its time sleeping, it will
> use very little in the way of system resources.
>
> Good luck,
> Bill
>

Thanks, Bill. That is definitely more of what I am looking for and actually
found that through some googling.  What I am confused about now, is what's
really the difference between py2app and the python Build Applet?



-- 
Michael J. Lewis
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[William R. Wing (Bill Wing)]

On Sep 1, 2012, at 11:29 PM, Michael Lewis  wrote:

> Hi everyone,
> 
> I am sorry to ask this when there are a lot of resources online regarding the 
> subject, but I've spent the past two days trying to figure this out and I 
> don't get it.
> 
> I have a script that will run forever. Since it runs forever, I don't want to 
> see the interpreter or command line. I want the program to run in the 
> background so I don't see it at all.
> 
> How can I do this? For some background, my script essentially check every x 
> minutes to see if any files have been updated and then moves them to dropbox.
> 
> I want to be able to do this on both OSX Mountain Lion and Windows 7. If need 
> be, I can create two separate scripts to separate out the two OS's.
> 
> Thanks!
> 
> -- 
> Michael J. Lewis

Michael, I see you have several Windows answers, but it doesn't look as though 
you found quite what you were hoping for on OSX.  My suggestion would be to 
take the script and run it through py2app, which will turn it into a 
stand-alone application which can then be added to your list of StartUp or 
LogIn applications.  If you never request input or produce output, it will 
quite happily run in the background with no window and no menu (although by 
default there will be an icon in the dock).  At that point it is so much a 
background application that the ONLY way you can quit it is via the Force Quit 
dialog.   If you generate status or housekeeping print messages, they will show 
up in ~/Library/Logfiles.  Py2app isn't particularly memory efficient, even a 
minimal application tends to run close to 9-10 Mbytes, but if it spends most of 
its time sleeping, it will use very little in the way of system resources.

If you want it to run even when you aren't logged in, you will have to go to a 
bit more trouble.  You will have to make up an installer plist file and use 
launchctl to add it to the list of stuff under control of the launchd daemon.

Good luck,
Bill
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Alan Gauld]

On 02/09/12 04:29, Michael Lewis wrote:


I have a script that will run forever. Since it runs forever, I don't
want to see the interpreter or command line. I want the program to run
in the background so I don't see it at all.


That's an OS thing not a Python thing.

On Unix it means adding an entry in the startup scripts.
For an old BSD type like me that was one of the init scripts in the /etc 
tree but nowadays there are different mechanisms, and I'm especially 
unclear on how MacOS/Darwin starts up. You'll need to do some Googling.


On windows you can just put it into the Run registry entry under the 
appropriate key. Again search the Microsoft help system for the answers.



How can I do this? For some background, my script essentially check
every x minutes to see if any files have been updated and then moves
them to dropbox.


In that case using a long running Python script is probably the wrong 
answer. You would be better with a short running, do it once, script 
that the OS launches regularly.


Look at 'cron' on *nix and 'at' on Windows.

That will be less resource hungry, there is no point in having running 
programs that do nothing for most of the time.




... I can create two separate scripts to separate out the two OS's.


One of the beauties of Python is that you rarely need separate scripts.
Put the file location(s) in a config file and the same script will work 
for both. Only the startup mechanism will differ.



HTH
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

Here's a little more reading for you, found under google search term 'no
terminal python script'

http://stackoverflow.com/questions/2338951/how-can-i-run-a-py2exe-program-in-windows-without-the-terminal

http://ginstrom.com/scribbles/2007/09/12/running-a-python-script-on-windows-without-the-console/

>
>


-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Dwight Hutto]

On Sat, Sep 1, 2012 at 11:29 PM, Michael Lewis  wrote:

> Hi everyone,
>
> I am sorry to ask this when there are a lot of resources online regarding
> the subject, but I've spent the past two days trying to figure this out and
> I don't get it.
>
> I have a script that will run forever
>

Forever is a very loose term.


> . Since it runs forever, I don't want to see the interpreter or command
> line. I want the program to run in the background so I don't see it at all.
>
> How can I do this? For some background, my script essentially check every
> x minutes to see if any files have been updated and then moves them to
> dropbox.
>
> I want to be able to do this on both OSX Mountain Lion and Windows 7. If
> need be, I can create two separate scripts to separate out the two OS's.
>
> I haven't tested this yet. I was about to use this instead of a cron job
for autoresponders. In my limited knowledge in this area, I'd think that
calling the script in startup/boot like this describes:

http://embraceubuntu.com/2005/09/07/adding-a-startup-script-to-be-run-at-bootup/

might help.

Or maybe a tkinter/wxpython app, that hides itself continuously, buit there
might still be a launched icon on the app bar your OS should have. I
haven't used OSX Mountain Lion, yet. I like looking at different OS setups.

-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com*
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[c smith]

You are thinking of &&
& is what you want
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Michael Lewis]

> For windows not sure but for osx just add an & after the command.
>
> python myscript.py &
>

Thanks, but I know about that. I should have been more clear. What I want
to do is have the script run in the background without even seeing the
terminal. Adding the & after the command will let do other things, but the
terminal still needs to be open. Once the program is running, I don't want
either the terminal or the interpreter displayed.

Thanks again.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Running a script in the background

[Michael Crawford]

For windows not sure but for osx just add an & after the command.

python myscript.py &

On Sep 1, 2012, at 11:29 PM, Michael Lewis  wrote:

> Hi everyone,
> 
> I am sorry to ask this when there are a lot of resources online regarding the 
> subject, but I've spent the past two days trying to figure this out and I 
> don't get it.
> 
> I have a script that will run forever. Since it runs forever, I don't want to 
> see the interpreter or command line. I want the program to run in the 
> background so I don't see it at all.
> 
> How can I do this? For some background, my script essentially check every x 
> minutes to see if any files have been updated and then moves them to dropbox.
> 
> I want to be able to do this on both OSX Mountain Lion and Windows 7. If need 
> be, I can create two separate scripts to separate out the two OS's.
> 
> Thanks!
> 
> -- 
> Michael J. Lewis
> 
> 
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor