 |
|
|
|
synopsys_shell - A Perl frontend interface to Synopsys' shells
|
|
|
unix% bc_perl
unix% budget_perl
unix% ca_perl
unix% dc_perl
unix% dp_perl
unix% dt_perl
unix% fpga_perl
unix% fm_perl
unix% lc_perl
unix% pt_perl
unix% ra_perl
|
|
|
|
|
|
synopsys_shell is an interactive perl frontend wrapper script for Synopsys'
shell products. synopsys_shell provides many features found in modern unix
shell interfaces like tcsh, bash, or zsh including command completion, history substitution, and arbitrary output
redirection.
It has a multi-mode operation (Dcsh, Tcl or Perl) with quick and easy Perl
evaluation for rapid development of new functions.
synopsys_shell supports context sensitive command, variable and command
argument completion in both Tcl and Dcsh mode, and it has a standard
interface to GNU Readline for quick customization of key bindings and
macros.
|
|
|
Throughout this document, the underlying Synopsys executable that was
forked (ie. dc_shell, pt_shell, etc) will be referred to as the Synopsys shell. This script, which can be invoked with any of names above, will be
referred to as synopsys_shell.
Many of the underlying Synopsys shells can run in either a default Dcsh
mode or a new Tcl mode. synopsys_shell supports both. Throughout this
document, the term Shell mode will be used to refer to when in either Dcsh or Tcl mode.
|
|
|
synopsys_shell uses SPP to control a Synopsys shell. synopsys_shell thus
requires everything that SPP requires. synopsys_shell also uses the GNU
readline library to provide the user interface. This requires that the GNU
readline library (version 2.1 or later) be installed as well as the perl
module that interfaces to that library, Term::ReadLine::Gnu (version 1.06
or later). synopsys_shell also requires the CPAN module Term::ANSIColor and
the bundled module CommandTerm.
|
|
|
synopsys_shell comes bundled with SPP and is installed by default.
|
|
|
synopsys_shell is not intended to be run directly. Instead, the SPP
installation process creates a symbolic link for each tool that SPP
supports. The name of the symbolic link is the same as the Synopsys shell
with the _shell in the name replaced with _perl:
bc_perl
budget_perl
ca_perl
dc_perl
dp_perl
dt_perl
fpga_perl
pm_perl
lc_perl
pt_perl
ra_perl
synopsys_shell figures out which Synopsys shell to invoke by inspecting $0.
synopsys_shell takes one command line option that it processes. A -verbose
<verbose_level> (or an abbreviation) can be supplied to set the verbose level of the
SPP object created. This can be useful to debug initialization problems.
The default value is 3 if no value is supplied.
Any other command line arguments will be sent to the Synopsys shell for
processing. See the documentation for a particular Synopsys shell for
details on the available command line options.
Once synopsys_shell has successfully started, a prompt is presented that
looks very similar to a normal shell prompt except that it will be printed
in bold and it will have either a -tcl or a -sh on the end of it depending on whether it was started in Dcsh mode or Tcl
mode. From here, the user is able to type any command that they could enter
with a regular Synopsys shell.
|
|
|
synopsys_shell is built around the standard GNU Readline interface. By
default, emacs key bindings are in effect for command line editing, use of
the arrow (up/down) keys will cycle through the command history, and
history substitution is available via Readline's history interface. See the
Builtin Commands section for a discussion of Readline history versus Tcl and Dcsh history
capability.
One non-default key binding is installed automatically by synopsys_shell:
Control-T is bound to toggle between regular command mode (the initial
mode) and perl evaluation mode. This binding and any others can be modified via the user's ~/.inputrc
file. The name synopsys
can be used in the ~/.inputrc to create bindings that would only be in
effect for synopsys_shell. Here is what my ~/.inputrc looks like:
$if synopsys
set bell-style none
$endif
The readline command toggle-perl-mode can be used to switch back and forth between Shell and Perl mode. To change toggle-perl-mode from Control-T to Control-P and to revert Control-T back to its default
setting add the following to your ~/.inputrc:
C-t: transpose-chars
C-p: toggle-perl-mode
See the GNU Readline documentation for a full explanation of supported key
bindings and macros.
The GNU Readline also provides enhanced history capability. The arrow
(up/down) keys can be used to cycle forward and backward through the
history list. GNU Readline history defines many types of history
substitution using the bang (!) notation. The user is directed to the GNU
Readline history documentation for details.
|
|
|
Input lines are minimally parsed to support the necessary internal
functions. The word break characters are:
" ' ; \s > >> |
Double and single quoted strings are preserved and they don't nest. Any
unmatched double or single quote is kept as a token by itself. All
unprotected white space is collapsed to a single space. Any character
preceded by a backslash (\) will be preserved but not interpolated. In Tcl
command mode, all single-quoted strings have their single-quotes removed
before being sent to the Synopsys shell while double-quoted strings are
preserved and sent as-is. In perl evaluation mode, single-quotes are maintained and passed to the perl interpreter when the
line is evaluated.
|
|
|
After the input line is parsed and broken into tokens, the first token is
taken to be a command name and executed based on the following priority:
- Builtin Command
-
If the first token is a builtin command, the command is executed with each subsequent token interpreted as a
command argument.
- Perl Subroutine
-
If the first token matches any subroutine defined in the synopsys_shell
namespace, the subroutine and its arguments are evaluated by the perl
interpreter and the return value is printed to the screen. Any subroutine
arguments are turned into a perl list before evaluation. For example, let's
say you've defined a subroutine foo in perl that takes a list as an argument. You could type this on the
command line:
foo bar $bax @baz
which would be transformed into this:
foo('bar', $bax, @baz,);
before being evaluated. Any argument that is a simple bareword is
surrounded by single quotes to avoid annoying warnings.
Executing perl subroutines from the Tcl mode command is designed to make it
convenient to run perl without switching to perl evaluation mode. Note that command completion is supported for defined perl subroutines.
- Synopsys shell Command
-
Finally, any other command is assumed to be a Synopsys shell command. If a
Synopsys shell command has the same name as either a builtin command or a
defined perl subroutine, it will not be executed based on this priority. To
bypass this ordering, use the run builtin command which sends a command directly to the Synopsys shell.
|
|
|
By default, synopsys_shell pages the output any man command and any command that begins with report_. synopsys_shell will use the program found in the environment variable
$PAGER if set or more. If neither executable is found, a warning message is printed at startup.
To disable paging for a particular man or report_* command simply pipe it's output to cat
using the Command Output Redirection
described below.
There is one subtle but noticeable difference between synopsys_shell paging
and the native paging provided by a Synopsys shell. Under a Synopsys shell,
a command like report_timing may initially produce many lines of output that aren't paged. For example,
many times a report_timing command will cause the linker to run and design
constraints to be updated. These operations can cause many pages of
informational output which a regular Synopsys shell will not page. However,
since synopsys_shell cannot differentiate between types of command output
(it's just text), all output will be paged.
|
|
|
Whereas the Synopsys shell provides only simple output redirection,
synopsys_shell provides more arbitrary output redirection using Perl's
builtin capabilities.
Commands can be redirected to files or other commands using the |, >, or
>> modifiers.
- Writing or Appending to a File
-
If the line parser finds a > or a >> somewhere on an input line it expects there to one and only one token
following the modifier. White space not need to precede or follow these
characters. The token following these characters is taken to be the name of
a file that will either be written or appended to.
- Redirecting to a Pipe
-
The line parser searches for a pipe (|) character left-to-right on an input
line. If it finds one it takes the rest of the command to be a command
pipe. Note that many commands can be strung together in the same way as a
regular shell. A good example is using grep to find more appropriate help than by using the help command. In dc_perl, compare the output of the following two commands:
help *collection* (only works in Tcl mode)
and
help * | grep collection
Many would consider the second's output more useful.
|
|
|
One of the most powerful features of synopsys_shell is its command
completion. Command completion in synopsys_shell is context sensitive in
Shell mode which great helps the user type long commands with proper
spelling and command line arguments.
Note that the context sensitive completion is only a heuristic. The input
lines are not parsed in a formal way. This being the case, it is easy to
create pathological cases which fool the completer. However, experience
shows that the completer will do what you expect most of the time.
By default, the command completion character is <TAB>, but that can be changed by modifying the complete variable in your ~/.inputrc.
- Shell Completion
-
- Commands
-
Any valid command is completed either at the beginning of the line or when
immediately preceded by a semi-colon (;) or a left-bracket ([) or
immediately following the run, man or help commands. Any valid command is defined to be any command returned by info commands, any
builtin command, any defined Synopsys shell alias, and any perl subroutine that was
evaluated using the perl evaluation mode.
This list is dynamically built so that any changes to the command list will
be reflected in how the completer works.
- Command Arguments
-
If the current token begins with a dash (-), the previous token will be
assumed to be a command with command line arguments. The completer will
list any appropriate command arguments for the given command. If no command
line arguments are defined for the command, or the command doesn't exist,
or the previous token is not a command, no completion takes place. For
example, in dc_perl, if the command:
compile -b<TAB><TAB>
is typed, the output is:
-background -bottom_up -boundary_optimization
Typing ou<TAB> will cause -boundary_optimization to be completed.
- Filenames, Usernames and Environment Variables
-
Filenames in the current directory and usernames are completed when it is
determined that the current command on the input line matches one in the
following list:
cd
do
include
ls
read*
source
sh
write*
Additionally, if the preceding token on the input line is a > or a
>>, filename and username completion is enabled regardless of the command.
Username completion is enabled anytime filename completion is enabled and
the token begins with a tilde (~).
- Variables
-
Tcl variables are completed when the command is either set or
printvar, or the first character of the token is a dollar sign ($).
Dcsh variables are completed when the command is list.
- Aliases
-
Shell aliases are completed anywhere regular commands are completed as well
when the command is alias.
- Environment Variables
-
Environment variables are completed when the current command is printenv.
- Perl Completion
-
Perl variable completion takes place when either in perl evaluation mode or in Shell mode and the current command is
dumpvar or any perl defined subroutine.
Perl variables include all scalars, lists, hashes, and subroutines in the
synopsys package.
|
|
|
synopsys_shell provides a convenient interface to rapidly develop and
execute perl code. To access perl mode, simply type Control-T (or whatever
you have bound to toggle-perl-mode in Readline). This will change the prompt to end in -perl. From then on, every command you type will be evaluated by the perl
interpreter.
Additionally, a private empty package has been created under which all user
code is evaluated. The name of the package is synopsys. You can assume the following lines have been executed for you when you
enter commands in perl mode:
package synopsys;
use Synopsys;
use Data::Dumper;
no strict;
use vars qw($shell);
$Data::Dumper::Indent = 1;
$Data::Dumper::Useqq = 1;
In fact, this is exactly the code which is executed before you enter
commands in perl mode (unless the Data::Dumper module isn't available at
your site).
The variable $shell is an alias to the like named variable in
the package
%main::. It's the SPP blessed object so the user has access to all the methods
defined by SPP.
Please note that no attempt is made to monitor this namespace. The user is
given enough rope to hang themselves and can do so easily by altering the
$shell variable.
The final return value of the statement entered on the line is printed to
the screen.
One of the most useful ways to use perl mode is to develop perl code in a
separate file and use the do builtin command to continually re-evaluate and re-execute the code. Much of
the code in SPP was written in just this way.
|
|
|
synopsys_shell provides a few builtin commands in addition the commands
provided by the Synopsys shell.
- history -h -r n
-
The history builtin is the only command that overrides the default history
command provided by the Synopsys shell. It is the opinion of the author
that the history functionality provided by GNU Readline is more
comprehensive and familiar to most users who use modern shells like tcsh, zsh, and
bash.
The history command itself tries to be compatible with the Synopsys shell
version of history. Keep in mind though that synopsys_shell keeps its own
history list and doesn't use the Synopsys shell history in any way.
synopsys_shell keeps an unlimited history list.
The -r option causes the history to be printed in reverse order.
The -h option causes the leading numbers to be omitted when printing the history.
The n option causes only n history items to be printed.
If the user wants to run the Synopsys shell version of the history command,
they can use the run builtin command to bypass normal command processing.
- dumpvar perl_variable
-
dumpvar is a convenience function that uses the Data::Dumper module to display the contents of a perl variable. Note that dumpvar should
be entered while in Shell mode even though its argument is a string
representing a perl variable.
- run synopsys_shell_command
-
The run command is provided as fail-safe method to run commands on the
Synopsys shell. run takes all of its arguments, makes a string out of them
and sends them unaltered to the Synopsys shell. run can be used as a first
step to determine whether a problem is with synopsys_shell or the Synopsys
shell.
- verbose verbose_level
-
The verbose command sets the verbose level of the SPP object. See the SPP
documentation for an explanation of the verbose levels.
- do perl_script_filename
-
Evaluate the perl script into the synopsys_shell package. This command
provides a convenient way to introduce perl code into the synopsys_shell
package without switching over to perl mode.
The last value returned by perl_script_filename is printed to the screen.
|
|
|
synopsys_shell supports two modes of multiline command processing. Each
mode is the same for Shell mode and Perl mode.
- Simple Multiline Commands
-
If an input line ends with a backslash character (\), the line is
interpreted as a simple multiline command. The next prompt will have the
> replaced with a ? to show that multiline command processing is in effect. The user can
continue to enter multiline command text as long as each line ends with a
forward slash.
When a line is received that doesn't end with a backslash, all the of the
preceding lines will be concatenated together and executed as a single
command.
- Extended Multiline Commands
-
If an input line contains only a backslash, the line is interpreted as the
beginning of an extended multiline command. The prompt is changed as above,
but now, succeeding lines do not have to end with a backslash to continue
the multiline command. In fact, any backslash at the end of a line in this
mode has no effect and is ignored.
To terminate the mode and process the input buffer, enter a line that only
contains a period. The period will not be included in the command.
The user can switch from simple to extended multiline command mode by
inputting a line with only a backslash. The previous simple multiline
command text will be included in the extended command text.
- Native Synopsys shell Multiline Commands
-
Synopsys shell supports multiline processing as well. Unfortunately, it is
not consistent across their tools, which makes it difficult to support. For
example, pt_shell outputs a "? " for every multiline command of text it receives, while dc_shell outputs
nothing. For this reason, it is impossible to detect that a native
multiline command has been issued when using dc_perl (or its derivatives).
If a native multiline command is detected under pt_perl, a warning message
is printed to the screen alerting the user and the user may continue.
However, once a native multiline command has been entered under dc_perl it
is impossible to continue without interrupting the given command. This is
usually accomplished by hitting Control-C and pressing return.
In theory, there should be no need for native multiline commands with any
Synopsys shell. Either use the supported multiline command modes or send a
long command string using semicolons as command separators.
|
|
|
Signal handling in synopsys_shell is very similar to signal handling in a
regular Synopsys shell with a few notable differences.
- SIGINT
-
If a SIGINT is caught by synopsys_shell (usually by typing Control-C) and
the current input line is not empty, then the line is killed and the SIGINT
is not sent to the Synopsys shell. If the line is empty, the SIGINT is sent
to the Synopsys shell. Most users will be familiar with this case. If the
Synopsys shell receives three SIGINTs in a row without receiving a newline,
it will terminate causing synopsys_shell to terminate. The user can avoid
this by hitting return after generating the SIGINT, if their goal was to
simply abort the current command.
- SIGPIPE
-
SIGPIPEs are ignored. When the user has redirected the output of a command to a pipe and exited the redirection before the Synopsys shell
command finished outputting, a SIGPIPE is delivered to synopsys_shell.
Thus, SIGPIPEs are ignored to avoid program termination when this occurs.
- SIGTERM
-
- SIGQUIT
-
If either a SIGTERM or a SIGQUIT is received, a SIGKILL is sent to the
Synopsys shell and synopsys_shell exits immediately.
|
|
|
Synopsys, Synopsys::Collection
|
|
|
Jeff Solomon <jsolomon@vlsi.stanford.edu>
|
|
|
|
|