[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 418
  • Last Modified:

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: "run_me.sh"

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

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

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


#wrapper script
/path-to/run_me.sh >> 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 run_me.sh.

run_me.sh 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.

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.


   "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 run_me.sh 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/run_me.sh >> mylogfile 2>&1 # a DOT space then /path-to/run_me.sh
/usr/bin/script -a mylogfile
Please remember to "export" your ENV var settings in " run_me.sh "

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/run_me.sh >> mylogfile 2>&1
. /path-to/run_me.sh

Because the run_me.sh 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

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now