Solaris / OpenSolarisThis forum is for the discussion of Solaris and OpenSolaris.
General Sun, SunOS and Sparc related questions also go here.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Please use ***[code][/code]*** tags around your code and data, to preserve the original formatting and to improve readability. Do not use quote tags, bolding, colors, "start/end" lines, or other creative techniques.

As stated, bash and most other sh-style shells run piped commands in subshells. This means any environment settings made in them are lost when the loop terminates. ksh, however, runs the final entry in the pipe chain in the main shell, and so this does work properly in it.

Note that bash has recently introduced a lastpipe shell option that does the same thing, but it conflicts with job management and so isn't enabled by default. It's also not recommended for interactive use because of this.

For all sh-based shells (including ksh), you can usually use some form of redirection for input instead.

Code:

while read line; do
echo "$line"
done < <( command )

The above uses bash's process substitution feature ( ksh also has P.S. but I believe it functions slightly differently, so be sure to check the documentation). You could instead use a here document/here string with a command substitution, or a named pipe, or an external tempfile, or any other similar kind of stdin feed.

Now to give you some other script pointers (links are for bash, but the general advice is applicable to all shells).

1) When you use "!#/bin/sh" as the shebang, your script will be interpreted according to POSIX compatibility, and the use of shell-specific features becomes questionable at best. This is usually not what you want, so always be sure to explicitly state the interpreter you want to use (e.g. /bin/bash or /bin/ksh ).

3) Lists of things should never be stored in a single scalar variable, except in the case of limited, POSIX-based shells. Always use arrays if the shell supports them, or process the input directly. I assume that "pkginfo -i" produces such a list.

If the shell doesn't support arrays then you have to be much more careful in how you handle such things. See the next point for why:

4) QUOTE ALL OF YOUR VARIABLE EXPANSIONS. You should never leave the quotes off a parameter expansion unless you explicitly want the resulting string to be word-split by the shell and possible globbing patterns expanded. This is a vitally important concept in scripting, so train yourself to do it correctly now. You can learn about the exceptions later.

1) When you use "!#/bin/sh" as the shebang, your script will be interpreted according to POSIX compatibility, and the use of shell-specific features becomes questionable at best.

While correct with Gnu/Linux and most Unix implementations, this feature is not mandated by POSIX and doesn't apply to Solaris up to version 10 with which /bin/sh is not a POSIX compliant shell but the original Bourne shell.

POSIX actually recommend not to use any shebang at all for a compatible script to run in a POSIX environment. Under Solaris, this environment is met by having /usr/xpg4/bin first in the PATH variable.