about summary refs log tree commit diff
path: root/manual/job.texi
blob: 24e1c94f2a8357694a6a6539609d0e0e9ecbc43d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
@node Job Control, Name Service Switch, Processes, Top
@c %MENU% All about process groups and sessions
@chapter Job Control

@cindex process groups
@cindex job control
@cindex job
@cindex session
@dfn{Job control} refers to the protocol for allowing a user to move
between multiple @dfn{process groups} (or @dfn{jobs}) within a single
@dfn{login session}.  The job control facilities are set up so that
appropriate behavior for most programs happens automatically and they
need not do anything special about job control.  So you can probably
ignore the material in this chapter unless you are writing a shell or
login program.

You need to be familiar with concepts relating to process creation
(@pxref{Process Creation Concepts}) and signal handling (@pxref{Signal
Handling}) in order to understand this material presented in this
chapter.

@menu
* Concepts of Job Control::     Jobs can be controlled by a shell.
* Job Control is Optional::     Not all POSIX systems support job control.
* Controlling Terminal::        How a process gets its controlling terminal.
* Access to the Terminal::      How processes share the controlling terminal.
* Orphaned Process Groups::     Jobs left after the user logs out.
* Implementing a Shell::        What a shell must do to implement job control.
* Functions for Job Control::   Functions to control process groups.
@end menu

@node Concepts of Job Control, Job Control is Optional,  , Job Control
@section Concepts of Job Control

@cindex shell
The fundamental purpose of an interactive shell is to read
commands from the user's terminal and create processes to execute the
programs specified by those commands.  It can do this using the
@code{fork} (@pxref{Creating a Process}) and @code{exec}
(@pxref{Executing a File}) functions.

A single command may run just one process---but often one command uses
several processes.  If you use the @samp{|} operator in a shell command,
you explicitly request several programs in their own processes.  But
even if you run just one program, it can use multiple processes
internally.  For example, a single compilation command such as @samp{cc
-c foo.c} typically uses four processes (though normally only two at any
given time).  If you run @code{make}, its job is to run other programs
in separate processes.

The processes belonging to a single command are called a @dfn{process
group} or @dfn{job}.  This is so that you can operate on all of them at
once.  For example, typing @kbd{C-c} sends the signal @code{SIGINT} to
terminate all the processes in the foreground process group.

@cindex session
A @dfn{session} is a larger group of processes.  Normally all the
processes that stem from a single login belong to the same session.

Every process belongs to a process group.  When a process is created, it
becomes a member of the same process group and session as its parent
process.  You can put it in another process group using the
@code{setpgid} function, provided the process group belongs to the same
session.

@cindex session leader
The only way to put a process in a different session is to make it the
initial process of a new session, or a @dfn{session leader}, using the
@code{setsid} function.  This also puts the session leader into a new
process group, and you can't move it out of that process group again.

Usually, new sessions are created by the system login program, and the
session leader is the process running the user's login shell.

@cindex controlling terminal
A shell that supports job control must arrange to control which job can
use the terminal at any time.  Otherwise there might be multiple jobs
trying to read from the terminal at once, and confusion about which
process should receive the input typed by the user.  To prevent this,
the shell must cooperate with the terminal driver using the protocol
described in this chapter.

@cindex foreground job
@cindex background job
The shell can give unlimited access to the controlling terminal to only
one process group at a time.  This is called the @dfn{foreground job} on
that controlling terminal.  Other process groups managed by the shell
that are executing without such access to the terminal are called
@dfn{background jobs}.

@cindex stopped job
If a background job needs to read from its controlling
terminal, it is @dfn{stopped} by the terminal driver; if the
@code{TOSTOP} mode is set, likewise for writing.  The user can stop
a foreground job by typing the SUSP character (@pxref{Special
Characters}) and a program can stop any job by sending it a
@code{SIGSTOP} signal.  It's the responsibility of the shell to notice
when jobs stop, to notify the user about them, and to provide mechanisms
for allowing the user to interactively continue stopped jobs and switch
jobs between foreground and background.

@xref{Access to the Terminal}, for more information about I/O to the
controlling terminal,

@node Job Control is Optional, Controlling Terminal, Concepts of Job Control , Job Control
@section Job Control is Optional
@cindex job control is optional

Not all operating systems support job control.  The GNU system does
support job control, but if you are using the GNU library on some other
system, that system may not support job control itself.

You can use the @code{_POSIX_JOB_CONTROL} macro to test at compile-time
whether the system supports job control.  @xref{System Options}.

If job control is not supported, then there can be only one process
group per session, which behaves as if it were always in the foreground.
The functions for creating additional process groups simply fail with
the error code @code{ENOSYS}.

The macros naming the various job control signals (@pxref{Job Control
Signals}) are defined even if job control is not supported.  However,
the system never generates these signals, and attempts to send a job
control signal or examine or specify their actions report errors or do
nothing.


@node Controlling Terminal, Access to the Terminal, Job Control is Optional, Job Control
@section Controlling Terminal of a Process

One of the attributes of a process is its controlling terminal.  Child
processes created with @code{fork} inherit the controlling terminal from
their parent process.  In this way, all the processes in a session
inherit the controlling terminal from the session leader.  A session
leader that has control of a terminal is called the @dfn{controlling
process} of that terminal.

@cindex controlling process
You generally do not need to worry about the exact mechanism used to
allocate a controlling terminal to a session, since it is done for you
by the system when you log in.
@c ??? How does GNU system let a process get a ctl terminal.

An individual process disconnects from its controlling terminal when it
calls @code{setsid} to become the leader of a new session.
@xref{Process Group Functions}.

@c !!! explain how it gets a new one (by opening any terminal)
@c ??? How you get a controlling terminal is system-dependent.
@c We should document how this will work in the GNU system when it is decided.
@c What Unix does is not clean and I don't think GNU should use that.

@node Access to the Terminal, Orphaned Process Groups, Controlling Terminal, Job Control
@section Access to the Controlling Terminal
@cindex controlling terminal, access to

Processes in the foreground job of a controlling terminal have
unrestricted access to that terminal; background processes do not.  This
section describes in more detail what happens when a process in a
background job tries to access its controlling terminal.

@cindex @code{SIGTTIN}, from background job
When a process in a background job tries to read from its controlling
terminal, the process group is usually sent a @code{SIGTTIN} signal.
This normally causes all of the processes in that group to stop (unless
they handle the signal and don't stop themselves).  However, if the
reading process is ignoring or blocking this signal, then @code{read}
fails with an @code{EIO} error instead.

@cindex @code{SIGTTOU}, from background job
Similarly, when a process in a background job tries to write to its
controlling terminal, the default behavior is to send a @code{SIGTTOU}
signal to the process group.  However, the behavior is modified by the
@code{TOSTOP} bit of the local modes flags (@pxref{Local Modes}).  If
this bit is not set (which is the default), then writing to the
controlling terminal is always permitted without sending a signal.
Writing is also permitted if the @code{SIGTTOU} signal is being ignored
or blocked by the writing process.

Most other terminal operations that a program can do are treated as
reading or as writing.  (The description of each operation should say
which.)

For more information about the primitive @code{read} and @code{write}
functions, see @ref{I/O Primitives}.


@node Orphaned Process Groups, Implementing a Shell, Access to the Terminal, Job Control
@section Orphaned Process Groups
@cindex orphaned process group

When a controlling process terminates, its terminal becomes free and a
new session can be established on it.  (In fact, another user could log
in on the terminal.)  This could cause a problem if any processes from
the old session are still trying to use that terminal.

To prevent problems, process groups that continue running even after the
session leader has terminated are marked as @dfn{orphaned process
groups}.

When a process group becomes an orphan, its processes are sent a
@code{SIGHUP} signal.  Ordinarily, this causes the processes to
terminate.  However, if a program ignores this signal or establishes a
handler for it (@pxref{Signal Handling}), it can continue running as in
the orphan process group even after its controlling process terminates;
but it still cannot access the terminal any more.

@node Implementing a Shell, Functions for Job Control, Orphaned Process Groups, Job Control
@section Implementing a Job Control Shell

This section describes what a shell must do to implement job control, by
presenting an extensive sample program to illustrate the concepts
involved.

@iftex
@itemize @bullet
@item
@ref{Data Structures}, introduces the example and presents
its primary data structures.

@item
@ref{Initializing the Shell}, discusses actions which the shell must
perform to prepare for job control.

@item
@ref{Launching Jobs}, includes information about how to create jobs
to execute commands.

@item
@ref{Foreground and Background}, discusses what the shell should
do differently when launching a job in the foreground as opposed to
a background job.

@item
@ref{Stopped and Terminated Jobs}, discusses reporting of job status
back to the shell.

@item
@ref{Continuing Stopped Jobs}, tells you how to continue jobs that
have been stopped.

@item
@ref{Missing Pieces}, discusses other parts of the shell.
@end itemize
@end iftex

@menu
* Data Structures::             Introduction to the sample shell.
* Initializing the Shell::      What the shell must do to take
				 responsibility for job control.
* Launching Jobs::              Creating jobs to execute commands.
* Foreground and Background::   Putting a job in foreground of background.
* Stopped and Terminated Jobs::  Reporting job status.
* Continuing Stopped Jobs::     How to continue a stopped job in
				 the foreground or background.
* Missing Pieces::              Other parts of the shell.
@end menu

@node Data Structures, Initializing the Shell,  , Implementing a Shell
@subsection Data Structures for the Shell

All of the program examples included in this chapter are part of
a simple shell program.  This section presents data structures
and utility functions which are used throughout the example.

The sample shell deals mainly with two data structures.  The
@code{job} type contains information about a job, which is a
set of subprocesses linked together with pipes.  The @code{process} type
holds information about a single subprocess.  Here are the relevant
data structure declarations:

@smallexample
@group
/* @r{A process is a single process.}  */
typedef struct process
@{
  struct process *next;       /* @r{next process in pipeline} */
  char **argv;                /* @r{for exec} */
  pid_t pid;                  /* @r{process ID} */
  char completed;             /* @r{true if process has completed} */
  char stopped;               /* @r{true if process has stopped} */
  int status;                 /* @r{reported status value} */
@} process;
@end group

@group
/* @r{A job is a pipeline of processes.}  */
typedef struct job
@{
  struct job *next;           /* @r{next active job} */
  char *command;              /* @r{command line, used for messages} */
  process *first_process;     /* @r{list of processes in this job} */
  pid_t pgid;                 /* @r{process group ID} */
  char notified;              /* @r{true if user told about stopped job} */
  struct termios tmodes;      /* @r{saved terminal modes} */
  int stdin, stdout, stderr;  /* @r{standard i/o channels} */
@} job;

/* @r{The active jobs are linked into a list.  This is its head.}   */
job *first_job = NULL;
@end group
@end smallexample

Here are some utility functions that are used for operating on @code{job}
objects.

@smallexample
@group
/* @r{Find the active job with the indicated @var{pgid}.}  */
job *
find_job (pid_t pgid)
@{
  job *j;

  for (j = first_job; j; j = j->next)
    if (j->pgid == pgid)
      return j;
  return NULL;
@}
@end group

@group
/* @r{Return true if all processes in the job have stopped or completed.}  */
int
job_is_stopped (job *j)
@{
  process *p;

  for (p = j->first_process; p; p = p->next)
    if (!p->completed && !p->stopped)
      return 0;
  return 1;
@}
@end group

@group
/* @r{Return true if all processes in the job have completed.}  */
int
job_is_completed (job *j)
@{
  process *p;

  for (p = j->first_process; p; p = p->next)
    if (!p->completed)
      return 0;
  return 1;
@}
@end group
@end smallexample


@node Initializing the Shell, Launching Jobs, Data Structures, Implementing a Shell
@subsection Initializing the Shell
@cindex job control, enabling
@cindex subshell

When a shell program that normally performs job control is started, it
has to be careful in case it has been invoked from another shell that is
already doing its own job control.

A subshell that runs interactively has to ensure that it has been placed
in the foreground by its parent shell before it can enable job control
itself.  It does this by getting its initial process group ID with the
@code{getpgrp} function, and comparing it to the process group ID of the
current foreground job associated with its controlling terminal (which
can be retrieved using the @code{tcgetpgrp} function).

If the subshell is not running as a foreground job, it must stop itself
by sending a @code{SIGTTIN} signal to its own process group.  It may not
arbitrarily put itself into the foreground; it must wait for the user to
tell the parent shell to do this.  If the subshell is continued again,
it should repeat the check and stop itself again if it is still not in
the foreground.

@cindex job control, enabling
Once the subshell has been placed into the foreground by its parent
shell, it can enable its own job control.  It does this by calling
@code{setpgid} to put itself into its own process group, and then
calling @code{tcsetpgrp} to place this process group into the
foreground.

When a shell enables job control, it should set itself to ignore all the
job control stop signals so that it doesn't accidentally stop itself.
You can do this by setting the action for all the stop signals to
@code{SIG_IGN}.

A subshell that runs non-interactively cannot and should not support job
control.  It must leave all processes it creates in the same process
group as the shell itself; this allows the non-interactive shell and its
child processes to be treated as a single job by the parent shell.  This
is easy to do---just don't use any of the job control primitives---but
you must remember to make the shell do it.


Here is the initialization code for the sample shell that shows how to
do all of this.

@smallexample
/* @r{Keep track of attributes of the shell.}  */

#include <sys/types.h>
#include <termios.h>
#include <unistd.h>

pid_t shell_pgid;
struct termios shell_tmodes;
int shell_terminal;
int shell_is_interactive;


/* @r{Make sure the shell is running interactively as the foreground job}
   @r{before proceeding.} */

void
init_shell ()
@{

  /* @r{See if we are running interactively.}  */
  shell_terminal = STDIN_FILENO;
  shell_is_interactive = isatty (shell_terminal);

  if (shell_is_interactive)
    @{
      /* @r{Loop until we are in the foreground.}  */
      while (tcgetpgrp (shell_terminal) != (shell_pgid = getpgrp ()))
        kill (- shell_pgid, SIGTTIN);

      /* @r{Ignore interactive and job-control signals.}  */
      signal (SIGINT, SIG_IGN);
      signal (SIGQUIT, SIG_IGN);
      signal (SIGTSTP, SIG_IGN);
      signal (SIGTTIN, SIG_IGN);
      signal (SIGTTOU, SIG_IGN);
      signal (SIGCHLD, SIG_IGN);

      /* @r{Put ourselves in our own process group.}  */
      shell_pgid = getpid ();
      if (setpgid (shell_pgid, shell_pgid) < 0)
        @{
          perror ("Couldn't put the shell in its own process group");
          exit (1);
        @}

      /* @r{Grab control of the terminal.}  */
      tcsetpgrp (shell_terminal, shell_pgid);

      /* @r{Save default terminal attributes for shell.}  */
      tcgetattr (shell_terminal, &shell_tmodes);
    @}
@}
@end smallexample


@node Launching Jobs, Foreground and Background, Initializing the Shell, Implementing a Shell
@subsection Launching Jobs
@cindex launching jobs

Once the shell has taken responsibility for performing job control on
its controlling terminal, it can launch jobs in response to commands
typed by the user.

To create the processes in a process group, you use the same @code{fork}
and @code{exec} functions described in @ref{Process Creation Concepts}.
Since there are multiple child processes involved, though, things are a
little more complicated and you must be careful to do things in the
right order.  Otherwise, nasty race conditions can result.

You have two choices for how to structure the tree of parent-child
relationships among the processes.  You can either make all the
processes in the process group be children of the shell process, or you
can make one process in group be the ancestor of all the other processes
in that group.  The sample shell program presented in this chapter uses
the first approach because it makes bookkeeping somewhat simpler.

@cindex process group leader
@cindex process group ID
As each process is forked, it should put itself in the new process group
by calling @code{setpgid}; see @ref{Process Group Functions}.  The first
process in the new group becomes its @dfn{process group leader}, and its
process ID becomes the @dfn{process group ID} for the group.

@cindex race conditions, relating to job control
The shell should also call @code{setpgid} to put each of its child
processes into the new process group.  This is because there is a
potential timing problem: each child process must be put in the process
group before it begins executing a new program, and the shell depends on
having all the child processes in the group before it continues
executing.  If both the child processes and the shell call
@code{setpgid}, this ensures that the right things happen no matter which
process gets to it first.

If the job is being launched as a foreground job, the new process group
also needs to be put into the foreground on the controlling terminal
using @code{tcsetpgrp}.  Again, this should be done by the shell as well
as by each of its child processes, to avoid race conditions.

The next thing each child process should do is to reset its signal
actions.

During initialization, the shell process set itself to ignore job
control signals; see @ref{Initializing the Shell}.  As a result, any child
processes it creates also ignore these signals by inheritance.  This is
definitely undesirable, so each child process should explicitly set the
actions for these signals back to @code{SIG_DFL} just after it is forked.

Since shells follow this convention, applications can assume that they
inherit the correct handling of these signals from the parent process.
But every application has a responsibility not to mess up the handling
of stop signals.  Applications that disable the normal interpretation of
the SUSP character should provide some other mechanism for the user to
stop the job.  When the user invokes this mechanism, the program should
send a @code{SIGTSTP} signal to the process group of the process, not
just to the process itself.  @xref{Signaling Another Process}.

Finally, each child process should call @code{exec} in the normal way.
This is also the point at which redirection of the standard input and
output channels should be handled.  @xref{Duplicating Descriptors},
for an explanation of how to do this.

Here is the function from the sample shell program that is responsible
for launching a program.  The function is executed by each child process
immediately after it has been forked by the shell, and never returns.

@smallexample
void
launch_process (process *p, pid_t pgid,
                int infile, int outfile, int errfile,
                int foreground)
@{
  pid_t pid;

  if (shell_is_interactive)
    @{
      /* @r{Put the process into the process group and give the process group}
         @r{the terminal, if appropriate.}
         @r{This has to be done both by the shell and in the individual}
         @r{child processes because of potential race conditions.}  */
      pid = getpid ();
      if (pgid == 0) pgid = pid;
      setpgid (pid, pgid);
      if (foreground)
        tcsetpgrp (shell_terminal, pgid);

      /* @r{Set the handling for job control signals back to the default.}  */
      signal (SIGINT, SIG_DFL);
      signal (SIGQUIT, SIG_DFL);
      signal (SIGTSTP, SIG_DFL);
      signal (SIGTTIN, SIG_DFL);
      signal (SIGTTOU, SIG_DFL);
      signal (SIGCHLD, SIG_DFL);
    @}

  /* @r{Set the standard input/output channels of the new process.}  */
  if (infile != STDIN_FILENO)
    @{
      dup2 (infile, STDIN_FILENO);
      close (infile);
    @}
  if (outfile != STDOUT_FILENO)
    @{
      dup2 (outfile, STDOUT_FILENO);
      close (outfile);
    @}
  if (errfile != STDERR_FILENO)
    @{
      dup2 (errfile, STDERR_FILENO);
      close (errfile);
    @}

  /* @r{Exec the new process.  Make sure we exit.}  */
  execvp (p->argv[0], p->argv);
  perror ("execvp");
  exit (1);
@}
@end smallexample

If the shell is not running interactively, this function does not do
anything with process groups or signals.  Remember that a shell not
performing job control must keep all of its subprocesses in the same
process group as the shell itself.

Next, here is the function that actually launches a complete job.
After creating the child processes, this function calls some other
functions to put the newly created job into the foreground or background;
these are discussed in @ref{Foreground and Background}.

@smallexample
void
launch_job (job *j, int foreground)
@{
  process *p;
  pid_t pid;
  int mypipe[2], infile, outfile;

  infile = j->stdin;
  for (p = j->first_process; p; p = p->next)
    @{
      /* @r{Set up pipes, if necessary.}  */
      if (p->next)
        @{
          if (pipe (mypipe) < 0)
            @{
              perror ("pipe");
              exit (1);
            @}
          outfile = mypipe[1];
        @}
      else
        outfile = j->stdout;

      /* @r{Fork the child processes.}  */
      pid = fork ();
      if (pid == 0)
        /* @r{This is the child process.}  */
        launch_process (p, j->pgid, infile,
                        outfile, j->stderr, foreground);
      else if (pid < 0)
        @{
          /* @r{The fork failed.}  */
          perror ("fork");
          exit (1);
        @}
      else
        @{
          /* @r{This is the parent process.}  */
          p->pid = pid;
          if (shell_is_interactive)
            @{
              if (!j->pgid)
                j->pgid = pid;
              setpgid (pid, j->pgid);
            @}
        @}

      /* @r{Clean up after pipes.}  */
      if (infile != j->stdin)
        close (infile);
      if (outfile != j->stdout)
        close (outfile);
      infile = mypipe[0];
    @}

  format_job_info (j, "launched");

  if (!shell_is_interactive)
    wait_for_job (j);
  else if (foreground)
    put_job_in_foreground (j, 0);
  else
    put_job_in_background (j, 0);
@}
@end smallexample


@node Foreground and Background, Stopped and Terminated Jobs, Launching Jobs, Implementing a Shell
@subsection Foreground and Background

Now let's consider what actions must be taken by the shell when it
launches a job into the foreground, and how this differs from what
must be done when a background job is launched.

@cindex foreground job, launching
When a foreground job is launched, the shell must first give it access
to the controlling terminal by calling @code{tcsetpgrp}.  Then, the
shell should wait for processes in that process group to terminate or
stop.  This is discussed in more detail in @ref{Stopped and Terminated
Jobs}.

When all of the processes in the group have either completed or stopped,
the shell should regain control of the terminal for its own process
group by calling @code{tcsetpgrp} again.  Since stop signals caused by
I/O from a background process or a SUSP character typed by the user
are sent to the process group, normally all the processes in the job
stop together.

The foreground job may have left the terminal in a strange state, so the
shell should restore its own saved terminal modes before continuing.  In
case the job is merely been stopped, the shell should first save the
current terminal modes so that it can restore them later if the job is
continued.  The functions for dealing with terminal modes are
@code{tcgetattr} and @code{tcsetattr}; these are described in
@ref{Terminal Modes}.

Here is the sample shell's function for doing all of this.

@smallexample
@group
/* @r{Put job @var{j} in the foreground.  If @var{cont} is nonzero,}
   @r{restore the saved terminal modes and send the process group a}
   @r{@code{SIGCONT} signal to wake it up before we block.}  */

void
put_job_in_foreground (job *j, int cont)
@{
  /* @r{Put the job into the foreground.}  */
  tcsetpgrp (shell_terminal, j->pgid);
@end group

@group
  /* @r{Send the job a continue signal, if necessary.}  */
  if (cont)
    @{
      tcsetattr (shell_terminal, TCSADRAIN, &j->tmodes);
      if (kill (- j->pgid, SIGCONT) < 0)
        perror ("kill (SIGCONT)");
    @}
@end group

  /* @r{Wait for it to report.}  */
  wait_for_job (j);

  /* @r{Put the shell back in the foreground.}  */
  tcsetpgrp (shell_terminal, shell_pgid);

@group
  /* @r{Restore the shell's terminal modes.}  */
  tcgetattr (shell_terminal, &j->tmodes);
  tcsetattr (shell_terminal, TCSADRAIN, &shell_tmodes);
@}
@end group
@end smallexample

@cindex background job, launching
If the process group is launched as a background job, the shell should
remain in the foreground itself and continue to read commands from
the terminal.

In the sample shell, there is not much that needs to be done to put
a job into the background.  Here is the function it uses:

@smallexample
/* @r{Put a job in the background.  If the cont argument is true, send}
   @r{the process group a @code{SIGCONT} signal to wake it up.}  */

void
put_job_in_background (job *j, int cont)
@{
  /* @r{Send the job a continue signal, if necessary.}  */
  if (cont)
    if (kill (-j->pgid, SIGCONT) < 0)
      perror ("kill (SIGCONT)");
@}
@end smallexample


@node Stopped and Terminated Jobs, Continuing Stopped Jobs, Foreground and Background, Implementing a Shell
@subsection Stopped and Terminated Jobs

@cindex stopped jobs, detecting
@cindex terminated jobs, detecting
When a foreground process is launched, the shell must block until all of
the processes in that job have either terminated or stopped.  It can do
this by calling the @code{waitpid} function; see @ref{Process
Completion}.  Use the @code{WUNTRACED} option so that status is reported
for processes that stop as well as processes that terminate.

The shell must also check on the status of background jobs so that it
can report terminated and stopped jobs to the user; this can be done by
calling @code{waitpid} with the @code{WNOHANG} option.  A good place to
put a such a check for terminated and stopped jobs is just before
prompting for a new command.

@cindex @code{SIGCHLD}, handling of
The shell can also receive asynchronous notification that there is
status information available for a child process by establishing a
handler for @code{SIGCHLD} signals.  @xref{Signal Handling}.

In the sample shell program, the @code{SIGCHLD} signal is normally
ignored.  This is to avoid reentrancy problems involving the global data
structures the shell manipulates.  But at specific times when the shell
is not using these data structures---such as when it is waiting for
input on the terminal---it makes sense to enable a handler for
@code{SIGCHLD}.  The same function that is used to do the synchronous
status checks (@code{do_job_notification}, in this case) can also be
called from within this handler.

Here are the parts of the sample shell program that deal with checking
the status of jobs and reporting the information to the user.

@smallexample
@group
/* @r{Store the status of the process @var{pid} that was returned by waitpid.}
   @r{Return 0 if all went well, nonzero otherwise.}  */

int
mark_process_status (pid_t pid, int status)
@{
  job *j;
  process *p;
@end group

@group
  if (pid > 0)
    @{
      /* @r{Update the record for the process.}  */
      for (j = first_job; j; j = j->next)
        for (p = j->first_process; p; p = p->next)
          if (p->pid == pid)
            @{
              p->status = status;
              if (WIFSTOPPED (status))
                p->stopped = 1;
              else
                @{
                  p->completed = 1;
                  if (WIFSIGNALED (status))
                    fprintf (stderr, "%d: Terminated by signal %d.\n",
                             (int) pid, WTERMSIG (p->status));
                @}
              return 0;
             @}
      fprintf (stderr, "No child process %d.\n", pid);
      return -1;
    @}
@end group
@group
  else if (pid == 0 || errno == ECHILD)
    /* @r{No processes ready to report.}  */
    return -1;
  else @{
    /* @r{Other weird errors.}  */
    perror ("waitpid");
    return -1;
  @}
@}
@end group

@group
/* @r{Check for processes that have status information available,}
   @r{without blocking.}  */

void
update_status (void)
@{
  int status;
  pid_t pid;

  do
    pid = waitpid (WAIT_ANY, &status, WUNTRACED|WNOHANG);
  while (!mark_process_status (pid, status));
@}
@end group

@group
/* @r{Check for processes that have status information available,}
   @r{blocking until all processes in the given job have reported.}  */

void
wait_for_job (job *j)
@{
  int status;
  pid_t pid;

  do
    pid = waitpid (WAIT_ANY, &status, WUNTRACED);
  while (!mark_process_status (pid, status)
         && !job_is_stopped (j)
         && !job_is_completed (j));
@}
@end group

@group
/* @r{Format information about job status for the user to look at.}  */

void
format_job_info (job *j, const char *status)
@{
  fprintf (stderr, "%ld (%s): %s\n", (long)j->pgid, status, j->command);
@}
@end group

@group
/* @r{Notify the user about stopped or terminated jobs.}
   @r{Delete terminated jobs from the active job list.}  */

void
do_job_notification (void)
@{
  job *j, *jlast, *jnext;
  process *p;

  /* @r{Update status information for child processes.}  */
  update_status ();

  jlast = NULL;
  for (j = first_job; j; j = jnext)
    @{
      jnext = j->next;

      /* @r{If all processes have completed, tell the user the job has}
         @r{completed and delete it from the list of active jobs.}  */
      if (job_is_completed (j)) @{
        format_job_info (j, "completed");
        if (jlast)
          jlast->next = jnext;
        else
          first_job = jnext;
        free_job (j);
      @}

      /* @r{Notify the user about stopped jobs,}
         @r{marking them so that we won't do this more than once.}  */
      else if (job_is_stopped (j) && !j->notified) @{
        format_job_info (j, "stopped");
        j->notified = 1;
        jlast = j;
      @}

      /* @r{Don't say anything about jobs that are still running.}  */
      else
        jlast = j;
    @}
@}
@end group
@end smallexample

@node Continuing Stopped Jobs, Missing Pieces, Stopped and Terminated Jobs, Implementing a Shell
@subsection Continuing Stopped Jobs

@cindex stopped jobs, continuing
The shell can continue a stopped job by sending a @code{SIGCONT} signal
to its process group.  If the job is being continued in the foreground,
the shell should first invoke @code{tcsetpgrp} to give the job access to
the terminal, and restore the saved terminal settings.  After continuing
a job in the foreground, the shell should wait for the job to stop or
complete, as if the job had just been launched in the foreground.

The sample shell program handles both newly created and continued jobs
with the same pair of functions, @w{@code{put_job_in_foreground}} and
@w{@code{put_job_in_background}}.  The definitions of these functions
were given in @ref{Foreground and Background}.  When continuing a
stopped job, a nonzero value is passed as the @var{cont} argument to
ensure that the @code{SIGCONT} signal is sent and the terminal modes
reset, as appropriate.

This leaves only a function for updating the shell's internal bookkeeping
about the job being continued:

@smallexample
@group
/* @r{Mark a stopped job J as being running again.}  */

void
mark_job_as_running (job *j)
@{
  Process *p;

  for (p = j->first_process; p; p = p->next)
    p->stopped = 0;
  j->notified = 0;
@}
@end group

@group
/* @r{Continue the job J.}  */

void
continue_job (job *j, int foreground)
@{
  mark_job_as_running (j);
  if (foreground)
    put_job_in_foreground (j, 1);
  else
    put_job_in_background (j, 1);
@}
@end group
@end smallexample

@node Missing Pieces,  , Continuing Stopped Jobs, Implementing a Shell
@subsection The Missing Pieces

The code extracts for the sample shell included in this chapter are only
a part of the entire shell program.  In particular, nothing at all has
been said about how @code{job} and @code{program} data structures are
allocated and initialized.

Most real shells provide a complex user interface that has support for
a command language; variables; abbreviations, substitutions, and pattern
matching on file names; and the like.  All of this is far too complicated
to explain here!  Instead, we have concentrated on showing how to
implement the core process creation and job control functions that can
be called from such a shell.

Here is a table summarizing the major entry points we have presented:

@table @code
@item void init_shell (void)
Initialize the shell's internal state.  @xref{Initializing the
Shell}.

@item void launch_job (job *@var{j}, int @var{foreground})
Launch the job @var{j} as either a foreground or background job.
@xref{Launching Jobs}.

@item void do_job_notification (void)
Check for and report any jobs that have terminated or stopped.  Can be
called synchronously or within a handler for @code{SIGCHLD} signals.
@xref{Stopped and Terminated Jobs}.

@item void continue_job (job *@var{j}, int @var{foreground})
Continue the job @var{j}.  @xref{Continuing Stopped Jobs}.
@end table

Of course, a real shell would also want to provide other functions for
managing jobs.  For example, it would be useful to have commands to list
all active jobs or to send a signal (such as @code{SIGKILL}) to a job.


@node Functions for Job Control,  , Implementing a Shell, Job Control
@section Functions for Job Control
@cindex process group functions
@cindex job control functions

This section contains detailed descriptions of the functions relating
to job control.

@menu
* Identifying the Terminal::    Determining the controlling terminal's name.
* Process Group Functions::     Functions for manipulating process groups.
* Terminal Access Functions::   Functions for controlling terminal access.
@end menu


@node Identifying the Terminal, Process Group Functions,  , Functions for Job Control
@subsection Identifying the Controlling Terminal
@cindex controlling terminal, determining

You can use the @code{ctermid} function to get a file name that you can
use to open the controlling terminal.  In the GNU library, it returns
the same string all the time: @code{"/dev/tty"}.  That is a special
``magic'' file name that refers to the controlling terminal of the
current process (if it has one).  To find the name of the specific
terminal device, use @code{ttyname}; @pxref{Is It a Terminal}.

The function @code{ctermid} is declared in the header file
@file{stdio.h}.
@pindex stdio.h

@comment stdio.h
@comment POSIX.1
@deftypefun {char *} ctermid (char *@var{string})
The @code{ctermid} function returns a string containing the file name of
the controlling terminal for the current process.  If @var{string} is
not a null pointer, it should be an array that can hold at least
@code{L_ctermid} characters; the string is returned in this array.
Otherwise, a pointer to a string in a static area is returned, which
might get overwritten on subsequent calls to this function.

An empty string is returned if the file name cannot be determined for
any reason.  Even if a file name is returned, access to the file it
represents is not guaranteed.
@end deftypefun

@comment stdio.h
@comment POSIX.1
@deftypevr Macro int L_ctermid
The value of this macro is an integer constant expression that
represents the size of a string large enough to hold the file name
returned by @code{ctermid}.
@end deftypevr

See also the @code{isatty} and @code{ttyname} functions, in
@ref{Is It a Terminal}.


@node Process Group Functions, Terminal Access Functions, Identifying the Terminal, Functions for Job Control
@subsection Process Group Functions

Here are descriptions of the functions for manipulating process groups.
Your program should include the header files @file{sys/types.h} and
@file{unistd.h} to use these functions.
@pindex unistd.h
@pindex sys/types.h

@comment unistd.h
@comment POSIX.1
@deftypefun pid_t setsid (void)
The @code{setsid} function creates a new session.  The calling process
becomes the session leader, and is put in a new process group whose
process group ID is the same as the process ID of that process.  There
are initially no other processes in the new process group, and no other
process groups in the new session.

This function also makes the calling process have no controlling terminal.

The @code{setsid} function returns the new process group ID of the
calling process if successful.  A return value of @code{-1} indicates an
error.  The following @code{errno} error conditions are defined for this
function:

@table @code
@item EPERM
The calling process is already a process group leader, or there is
already another process group around that has the same process group ID.
@end table
@end deftypefun

@comment unistd.h
@comment SVID
@deftypefun pid_t getsid (pid_t @var{pid})

The @code{getsid} function returns the process group ID of the session
leader of the specified process.  If a @var{pid} is @code{0}, the
process group ID of the session leader of the current process is
returned.

In case of error @code{-1} is returned and @code{errno} is set.  The
following @code{errno} error conditions are defined for this function:

@table @code
@item ESRCH
There is no process with the given process ID @var{pid}.
@item EPERM
The calling process and the process specified by @var{pid} are in
different sessions, and the implementation doesn't allow to access the
process group ID of the session leader of the process with ID @var{pid}
from the calling process.
@end table
@end deftypefun

The @code{getpgrp} function has two definitions: one derived from BSD
Unix, and one from the POSIX.1 standard.  The feature test macros you
have selected (@pxref{Feature Test Macros}) determine which definition
you get.  Specifically, you get the BSD version if you define
@code{_BSD_SOURCE}; otherwise, you get the POSIX version if you define
@code{_POSIX_SOURCE} or @code{_GNU_SOURCE}.  Programs written for old
BSD systems will not include @file{unistd.h}, which defines
@code{getpgrp} specially under @code{_BSD_SOURCE}.  You must link such
programs with the @code{-lbsd-compat} option to get the BSD definition.@refill
@pindex -lbsd-compat
@pindex bsd-compat
@cindex BSD compatibility library

@comment unistd.h
@comment POSIX.1
@deftypefn {POSIX.1 Function} pid_t getpgrp (void)
The POSIX.1 definition of @code{getpgrp} returns the process group ID of
the calling process.
@end deftypefn

@comment unistd.h
@comment BSD
@deftypefn {BSD Function} pid_t getpgrp (pid_t @var{pid})
The BSD definition of @code{getpgrp} returns the process group ID of the
process @var{pid}.  You can supply a value of @code{0} for the @var{pid}
argument to get information about the calling process.
@end deftypefn

@comment unistd.h
@comment SVID
@deftypefn {System V Function} int getpgid (pid_t @var{pid})

@code{getpgid} is the same as the BSD function @code{getpgrp}.  It
returns the process group ID of the process @var{pid}.  You can supply a
value of @code{0} for the @var{pid} argument to get information about
the calling process.

In case of error @code{-1} is returned and @code{errno} is set.  The
following @code{errno} error conditions are defined for this function:

@table @code
@item ESRCH
There is no process with the given process ID @var{pid}.
The calling process and the process specified by @var{pid} are in
different sessions, and the implementation doesn't allow to access the
process group ID of the process with ID @var{pid} from the calling
process.
@end table
@end deftypefn

@comment unistd.h
@comment POSIX.1
@deftypefun int setpgid (pid_t @var{pid}, pid_t @var{pgid})
The @code{setpgid} function puts the process @var{pid} into the process
group @var{pgid}.  As a special case, either @var{pid} or @var{pgid} can
be zero to indicate the process ID of the calling process.

This function fails on a system that does not support job control.
@xref{Job Control is Optional}, for more information.

If the operation is successful, @code{setpgid} returns zero.  Otherwise
it returns @code{-1}.  The following @code{errno} error conditions are
defined for this function:

@table @code
@item EACCES
The child process named by @var{pid} has executed an @code{exec}
function since it was forked.

@item EINVAL
The value of the @var{pgid} is not valid.

@item ENOSYS
The system doesn't support job control.

@item EPERM
The process indicated by the @var{pid} argument is a session leader,
or is not in the same session as the calling process, or the value of
the @var{pgid} argument doesn't match a process group ID in the same
session as the calling process.

@item ESRCH
The process indicated by the @var{pid} argument is not the calling
process or a child of the calling process.
@end table
@end deftypefun

@comment unistd.h
@comment BSD
@deftypefun int setpgrp (pid_t @var{pid}, pid_t @var{pgid})
This is the BSD Unix name for @code{setpgid}.  Both functions do exactly
the same thing.
@end deftypefun


@node Terminal Access Functions,  , Process Group Functions, Functions for Job Control
@subsection Functions for Controlling Terminal Access

These are the functions for reading or setting the foreground
process group of a terminal.  You should include the header files
@file{sys/types.h} and @file{unistd.h} in your application to use
these functions.
@pindex unistd.h
@pindex sys/types.h

Although these functions take a file descriptor argument to specify
the terminal device, the foreground job is associated with the terminal
file itself and not a particular open file descriptor.

@comment unistd.h
@comment POSIX.1
@deftypefun pid_t tcgetpgrp (int @var{filedes})
This function returns the process group ID of the foreground process
group associated with the terminal open on descriptor @var{filedes}.

If there is no foreground process group, the return value is a number
greater than @code{1} that does not match the process group ID of any
existing process group.  This can happen if all of the processes in the
job that was formerly the foreground job have terminated, and no other
job has yet been moved into the foreground.

In case of an error, a value of @code{-1} is returned.  The
following @code{errno} error conditions are defined for this function:

@table @code
@item EBADF
The @var{filedes} argument is not a valid file descriptor.

@item ENOSYS
The system doesn't support job control.

@item ENOTTY
The terminal file associated with the @var{filedes} argument isn't the
controlling terminal of the calling process.
@end table
@end deftypefun

@comment unistd.h
@comment POSIX.1
@deftypefun int tcsetpgrp (int @var{filedes}, pid_t @var{pgid})
This function is used to set a terminal's foreground process group ID.
The argument @var{filedes} is a descriptor which specifies the terminal;
@var{pgid} specifies the process group.  The calling process must be a
member of the same session as @var{pgid} and must have the same
controlling terminal.

For terminal access purposes, this function is treated as output.  If it
is called from a background process on its controlling terminal,
normally all processes in the process group are sent a @code{SIGTTOU}
signal.  The exception is if the calling process itself is ignoring or
blocking @code{SIGTTOU} signals, in which case the operation is
performed and no signal is sent.

If successful, @code{tcsetpgrp} returns @code{0}.  A return value of
@code{-1} indicates an error.  The following @code{errno} error
conditions are defined for this function:

@table @code
@item EBADF
The @var{filedes} argument is not a valid file descriptor.

@item EINVAL
The @var{pgid} argument is not valid.

@item ENOSYS
The system doesn't support job control.

@item ENOTTY
The @var{filedes} isn't the controlling terminal of the calling process.

@item EPERM
The @var{pgid} isn't a process group in the same session as the calling
process.
@end table
@end deftypefun

@comment termios.h
@comment Unix98
@deftypefun pid_t tcgetsid (int @var{fildes})
This function is used to obtain the process group ID of the session
for which terminal specified by @var{fildes} is the controlling terminal.
If the call is successful the group ID is returned.  Otherwise the
return value is @code{(pid_t) -1} and the global variable @var{errno}
is set to the following value:
@table @code
@item EBADF
The @var{filedes} argument is not a valid file descriptor.

@item ENOTTY
The calling process does not have a controlling terminal, or the file
ins not the controlling terminal.
@end table
@end deftypefun