Sponsored Content
Top Forums Programming Unix Shell background processing Post 302457729 by Mercfh on Tuesday 28th of September 2010 04:23:07 PM
Old 09-28-2010
here's an example of what im talking about.
myshell> ls -a
. .. a.out fork.c Hello .hi shell shell.c
myshell> ls -l
total 36
-rwxr-xr-x 1 matt matt 8435 2010-09-26 20:43 a.out
-rw-r--r-- 1 matt matt 943 2010-09-26 20:44 fork.c
drwxr-xr-x 2 matt matt 4096 2010-09-27 02:13 Hello
-rwxr-xr-x 1 matt matt 8322 2010-09-28 16:21 shell
-rw-r--r-- 1 matt matt 1693 2010-09-28 16:21 shell.c
myshell> ls &
myshell> a.out fork.c Hello shell shell.c
ls -a
myshell> . .. a.out fork.c Hello .hi shell shell.c
<---- here is where the "pointer" ends up. i can still type commands, but it doesn't show "myshell>" anymore

I tried the fprintf(stderr, "hello world\n"); thing. but it didn't work, it only happens when the & happens for some reason...

Looking at my code it should go like this.


parse arg. which prints out myshell>
User inputs commands<---
parse arg parses it.

so we have myshell> ls -l
so we execute it. which goes on a newline (apparently) (since BG is 0) and we wait for it to finish.
we then go back in the loop and myshell is printed again.

But with &....it goes back to parse arg (since we can still type things in, and they work) but myshell> isn't printed....which makes zero sense. Im looking at my code, tracing through....and I just dont see why this is happening, even when we aren't "waiting" the the process to finish, it should still loop back around to the parsearg function which has the myshell> printout.

It seems like typing in the & for SOME reason....like...screws all my printouts up.


edit: I think I may know why now.....im not resetting the BG bool to false, so it's treating them all as "background" processes i think........

edit2: CRAP nevermind, i realize im never setting BG permanently, oh well there goes that theory.

Last edited by Mercfh; 09-28-2010 at 06:34 PM..
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

background for unix

Hi, I am a newbie learing Unix , I have started with teh book "the Design of the Unix OS" by Bach.After which I plan to read "UNIX Network Programming" by Richard Stevens. What is the background that one needs to learn unix. I know C. But I am not sure about my Operating Systems... (4 Replies)
Discussion started by: ramyar
4 Replies

2. UNIX Desktop Questions & Answers

Unix Background

Hi, I'm new to this forums and to Unix OS... Is this the right place to put this thread? I just need to ask how to set the wallpaper that goes through the x-term windows in a Unix system? It's as if the x-term windows is transparent... I tried modifying the .login file and things got... (5 Replies)
Discussion started by: Gri3v3r7
5 Replies

3. Shell Programming and Scripting

Background shell script

I have a friend at work that asked me a question today and I figured I would seek help here. How does a shell script know whether it is running in the background or not? Thanks in advance for help (5 Replies)
Discussion started by: Moofasa
5 Replies

4. Shell Programming and Scripting

run a shell in the background

How can I run a shell in the background? cat test.sh #!/bin/sh sleep 600 Thank u very much indeed! (2 Replies)
Discussion started by: GCTEII
2 Replies

5. Linux

background processing in BASH

I have script 3 scripts 1 parent 2 children child1 child2 In the code below the 2 child processes fire almost Instantaneously in the background, Is that possible to know the status of pass/fail of each process "as it happens" ? In the present scenario although Child2... (5 Replies)
Discussion started by: jville
5 Replies

6. Shell Programming and Scripting

background processing in BASH

I have script 3 scripts 1 parent (p1) and 2 children child1 and child2 I have script 3 scripts 1 parent 2 children child1 child2 In the code below the 2 child processes fire almost Instantaneously in the background, Is that possible to know the status of pass/fail of each process... (12 Replies)
Discussion started by: jville
12 Replies

7. Shell Programming and Scripting

BASH - Handling background processes - distributed processing

NOTE: I am using BASH and Solaris 10 for this. Currently in the process of building a script that has a main "watcher" daemon that reads a configuration file and starts background processes based on it's global configuration. It is basically an infinite loop of configuration reading. Some of the... (4 Replies)
Discussion started by: dcarrion87
4 Replies

8. Programming

awk processing / Shell Script Processing to remove columns text file

Hello, I extracted a list of files in a directory with the command ls . However this is not my computer, so the ls functionality has been revamped so that it gives the filesizes in front like this : This is the output of ls command : I stored the output in a file filelist 1.1M... (5 Replies)
Discussion started by: ajayram
5 Replies

9. Shell Programming and Scripting

How to run multiple functions in Background in UNIX Shell Scripting?

Hi, I am using ksh , i have requirement to run 4 functions in background , 4 functions call are available in a case that case is also in function, i need to execute 1st function it should run in background and return to case and next i will call 2nd function it should run in background and... (8 Replies)
Discussion started by: karthikram
8 Replies

10. Shell Programming and Scripting

How to log file processing details to database table usnig UNIX shell script?

we are getting files on daily basis.we need to process these files. i need a unix shell script where we can count 1-The no of files processed 2-No of data/record processed for each files. The script should log these details into a database table. If there is any error while file... (3 Replies)
Discussion started by: Atul kumar
3 Replies
AnyEvent::Debug(3pm)					User Contributed Perl Documentation				      AnyEvent::Debug(3pm)

NAME
AnyEvent::Debug - debugging utilities for AnyEvent SYNOPSIS
use AnyEvent::Debug; # create an interactive shell into the program my $shell = AnyEvent::Debug::shell "unix/", "/home/schmorp/myshell"; # then on the shell: "socat readline /home/schmorp/myshell" DESCRIPTION
This module provides functionality hopefully useful for debugging. At the moment, "only" an interactive shell is implemented. This shell allows you to interactively "telnet into" your program and execute Perl code, e.g. to look at global variables. FUNCTIONS
$shell = AnyEvent::Debug::shell $host, $service This function binds on the given host and service port and returns a shell object, which determines the lifetime of the shell. Any number of conenctions are accepted on the port, and they will give you a very primitive shell that simply executes every line you enter. All commands will be executed "blockingly" with the socket "select"ed for output. For a less "blocking" interface see Coro::Debug. The commands will be executed in the "AnyEvent::Debug::shell" package, which currently has "help" and a few other commands, and can be freely modified by all shells. Code is evaluated under "use strict 'subs'". Every shell has a logging context ($LOGGER) that is attached to $AnyEvent::Log::COLLECT), which is especially useful to gether debug and trace messages. As a general programming guide, consider the beneficial aspects of using more global ("our") variables than local ones ("my") in package scope: Earlier all my modules tended to hide internal variables inside "my" variables, so users couldn't accidentally access them. Having interactive access to your programs changed that: having internal variables still in the global scope means you can debug them easier. As no authentication is done, in most cases it is best not to use a TCP port, but a unix domain socket, whcih can be put wherever you can access it, but not others: our $SHELL = AnyEvent::Debug::shell "unix/", "/home/schmorp/shell"; Then you can use a tool to connect to the shell, such as the ever versatile "socat", which in addition can give you readline support: socat readline /home/schmorp/shell # or: cd /home/schmorp; socat readline unix:shell Socat can even give you a persistent history: socat readline,history=.anyevent-history unix:shell Binding on 127.0.0.1 (or "::1") might be a less secure but sitll not totally insecure (on single-user machines) alternative to let you use other tools, such as telnet: our $SHELL = AnyEvent::Debug::shell "127.1", "1357"; And then: telnet localhost 1357 AnyEvent::Debug::wrap [$level] Sets the instrumenting/wrapping level of all watchers that are being created after this call. If no $level has been specified, then it toggles between 0 and 1. The default wrap level is 0, or whatever $ENV{PERL_ANYEVENT_DEBUG_WRAP} specifies. A level of 0 disables wrapping, i.e. AnyEvent works normally, and in its most efficient mode. A level of 1 or higher enables wrapping, which replaces all watchers by AnyEvent::Debug::Wrapped objects, stores the location where a watcher was created and wraps the callback to log all invocations at "trace" loglevel if tracing is enabled fore the watcher. The initial state of tracing when creating a watcher is taken from the global variable $AnyEvent:Debug::TRACE. The default value of that variable is 1, but it can make sense to set it to 0 and then do "local $AnyEvent::Debug::TRACE = 1" in a block where you create "interesting" watchers. Tracing can also be enabled and disabled later by calling the watcher's "trace" method. The wrapper will also count how many times the callback was invoked and will record up to ten runtime errors with corresponding backtraces. It will also log runtime errors at "error" loglevel. To see the trace messages, you can invoke your program with "PERL_ANYEVENT_VERBOSE=9", or you can use AnyEvent::Log to divert the trace messages in any way you like (the EXAMPLES section in AnyEvent::Log has some examples). A level of 2 does everything that level 1 does, but also stores a full backtrace of the location the watcher was created, which slows down watcher creation considerably. Every wrapped watcher will be linked into %AnyEvent::Debug::Wrapped, with its address as key. The "wl" command in the debug shell can be used to list watchers. Instrumenting can increase the size of each watcher multiple times, and, especially when backtraces are involved, also slows down watcher creation a lot. Also, enabling and disabling instrumentation will not recover the full performance that you had before wrapping (the AE::xxx functions will stay slower, for example). If you are developing your program, also consider using AnyEvent::Strict to check for common mistakes. AnyEvent::Debug::path2mod $path Tries to replace a path (e.g. the file name returned by caller) by a module name. Returns the path unchanged if it fails. Example: print AnyEvent::Debug::path2mod "/usr/lib/perl5/AnyEvent/Debug.pm"; # might print "AnyEvent::Debug" AnyEvent::Debug::cb2str $cb Using various gambits, tries to convert a callback (e.g. a code reference) into a more useful string. Very useful if you debug a program and have some callback, but you want to know where in the program the callback is actually defined. AnyEvent::Debug::backtrace [$skip] Creates a backtrace (actually an AnyEvent::Debug::Backtrace object that you can stringify), not unlike the Carp module would. Unlike the Carp module it resolves some references (such as callbacks) to more user-friendly strings, has a more succinct output format and most importantly: doesn't leak memory like hell. The reason it creates an object is to save time, as formatting can be done at a later time. Still, creating a backtrace is a relatively slow operation. THE AnyEvent::Debug::Wrapped CLASS All watchers created while the wrap level is non-zero will be wrapped inside an AnyEvent::Debug::Wrapped object. The address of the wrapped watcher will become its ID - every watcher will be stored in $AnyEvent::Debug::Wrapped{$id}. These wrapper objects can be stringified and have some methods defined on them. For debugging, of course, it can be helpful to look into these objects, which is why this is documented here, but this might change at any time in future versions. Each object is a relatively standard hash with the following members: type => name of the method used ot create the watcher (e.g. C<io>, C<timer>). w => the actual watcher rfile => reference to the filename of the file the watcher was created in line => line number where it was created sub => function name (or a special string) which created the watcher cur => if created inside another watcher callback, this is the string rep of the other watcher now => the timestamp (AE::now) when the watcher was created arg => the arguments used to create the watcher (sans C<cb>) cb => the original callback used to create the watcher called => the number of times the callback was called Each object supports the following mehtods (warning: these are only available on wrapped watchers, so are best for interactive use via the debug shell). $w->id Returns the numerical id of the watcher, as used in the debug shell. $w->verbose Returns a multiline textual description of the watcher, including the first ten exceptions caught while executing the callback. $w->trace ($on) Enables ($on is true) or disables ($on is false) tracing on this watcher. To get tracing messages, both the global logging settings must have trace messages enabled for the context "AnyEvent::Debug" and tracing must be enabled for the wrapped watcher. To enable trace messages globally, the simplest way is to start the program with "PERL_ANYEVENT_VERBOSE=9" in the environment. Tracing for each individual watcher is enabled by default (unless $AnyEvent::Debug::TRACE has been set to false). AUTHOR
Marc Lehmann <schmorp@schmorp.de> http://anyevent.schmorp.de perl v5.14.2 2012-04-08 AnyEvent::Debug(3pm)
All times are GMT -4. The time now is 01:55 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy