Screen logging: SCRIPT

When I type "script" at the Solaris console, a screen logging utility is started.  By default, it saves the log to a file called "typescript".

I've enabled this at the .login
exec script -a <filename>

When script is executed, I'd like to run a script called: ""

Is this behavior possible?  Does "script" execute another SHELL, that has it's own .login (to automatically run after script is executed)?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Not sure in what order to want to run "" and script (which one startup first).

You can use a wrapper script to do the the job:


#wrapper script
/path-to/ >> mylogfile 2>&1
/usr/bin/script -a mylogfile

in your .login file:
exec /path-to/myscript

man script
rambleAuthor Commented:
Order...well, when I start the command "script", I want it to run the sets some environmental variables, and such...

So, I believe what you posted is in the wrong order.

rambleAuthor Commented:
For example, when I type "script", I'm booted to the Bourne SHELL (sh), and, for example, I lose my PROMPT...I just get:

My Fancy Prompt> script
Script started, file is typescript

So...I type:

$ export PS1; PS1="My Fancy Prompt>";
My Fancy Prompt>

Now, I'm back to my prompt.  I want this (and other variables...and programs) to be ran when "script" is typed.

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.


   "script" command catches whatever show up on the screen including your typing after it issue.
So yuzh's wrapper script should have the wrong order as you suspect.
By the way, you need to put "set -x" or "#!/bin/sh -x" in your in order to show the environmental variables setting
on the screen (stdout and stderr).

rambleAuthor Commented:
OK, wesly, then how would it be modify to do what I'm needing it to do?

Or, was you just making a comment about the order...?
If you want to set ENV vars for the screen SHELL, you need to source the ENV setting files
before running script, the wrapper script would looks like:

#wrapper script
. /path-to/ >> mylogfile 2>&1 # a DOT space then /path-to/
/usr/bin/script -a mylogfile

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Please remember to "export" your ENV var settings in " "

source ENV setting file before running "script" is the correct order for this case.

rambleAuthor Commented:
OK...That's great yuzh.  It works.
Great information.  If you can expand on this question like, with the following, I'll increase to points to match...I appreciate it.

What's the difference between the DOT and the one without the DOT.
Can one script run BEFORE the "script" command, and one AFTER?

I'd like to suppress...or, at least, scroll or clear the screen so that the user doesn't see the:
"Script started, file is mylogfile" message.

I changed

. /path-to/ >> mylogfile 2>&1
. /path-to/

Because the script also contains a startup message...which doesn't need to be suppressed.

Thanks again.
What's the difference between the DOT and the one without the DOT.

The one with DOT acts like "soure" (C shell term) ENV file, it will import the ENV
settings from the  file to the current SHELL (if you put "export") in the file, the sub-shell
will also get the ENV setting which was exported.

The ONE without DOT, the setting only effect to its own self, when the script exit, all its
ENV setting disappear.

script start the shell it finds in the SHELL environment variable
this shell will start it's resource file according some other conditions
for csh/tcsh this is simple: .cshrc
for sh probably nothing ('cause it is not a login shell)
and for bash it get's complicated: most likely .bashrc

You need to read the proper man page, then simply edit your shell's resource file and add what you like
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.