So I am trying run a perl debugger inside another perl debugger. I keep readin tty in perl is the solution. Can someone explain to me what tty means ( is it terminal type?) and how is it useful? This is where I read it:
http://search.cpan.org/~rjbs/perl-5.18.0/lib/perl5db.pl#$CreateTTY
The reason I am trying to use tty is because of this question I asked:
Pass argument to perl file in debugger and set breakpoint in file executed by system
Thanks to all the ones who answer, the more you guys tell me what it is, better the idea I get :)
TTY (short for teletype) is basically a special input or output filehandle that connects to the terminal - namely, user input. For nitty gritty details, see:
Unix.SE in-depth answer on TTYs
Text Terminal HOWTO
This is what you need to know for starters (hard to say more since you didn't explain what you need to do with a TTY):
On Unix, it typically maps to /dev/tty device or similar
You can test for it using -t in Perl
As far as debugger, 2 things need to be known at least (if you intend to play with the TTY, the last paragraph is the most important). All data is near-quoted from perldoc perldebug
p expr prints to $DB::OUT filehandle (NOT STDOUT), which in turn is open to /dev/tty.
I think this may be controlled by LineInfo option from PERLDB_OPTS but never played with it so not sure.
Can be affected by the following $ENV{PERLDB_OPTS} options:
TTY - The TTY to use for debugging I/O.
noTTY - If set, the debugger goes into NonStop mode and will not connect to a TTY. If interrupted (or if control goes to the debugger via explicit setting of $DB::signal or $DB::single from the Perl script), it connects to a TTY specified in the TTY option at startup, or to a tty found at runtime using the Term::Rendezvous module of your choice.
This module should implement a method named new that returns an object with two methods: IN and OUT . These should return filehandles to use for debugging input and output correspondingly. The new method should inspect an argument containing the value of $ENV{PERLDB_NOTTY} at startup, or "$ENV{HOME}/.perldbtty$$" otherwise. This file is not inspected for proper ownership, so security hazards are theoretically possible.
Related
Is it possible to set the TERM environment variable for Emacs shell to some other value than "dumb"? In order to make TRAMP work I'm adjusting some parts of .bashrc on remote machines according to $TERM == "dumb" condition but for the shell I'd like these ignored (opposite approach - setting the TERM for TRUMP - would also be applicable).
Let me give your answer in two parts: first, one that technically answers your question but isn't very useful, and second, one that probably answers your needs even though it takes a different tack to get there.
Setting TERM in the shell
When starting shell-mode with M-x shell, Emacs starts the shell you want (usually the same as your login shell, but this can be changed if you really want to) and then sources a file, if it exists, based on the shell's name. The places it looks are
~/.emacs_$SHELLNAME
~/.emacs.d/init_${SHELLNAME}.sh
In this file you can set TERM. For instance, if you use zsh, and create the file
# ~/.emacs_zsh or ~/.emacs.d/init_zsh.sh
export TERM=emacs
then you'll get what you asked for: shells started with M-x shell will have the TERM set to emacs instead of dumb.
While this technically answers your question, though, it's not particularly useful—if you try it, here's what you'll get when you start a shell:
zsh: can't find terminal definition for emacs
$ echo $TERM
emacs
$
The issue here is that shell-mode doesn't implement any terminal emulation. In other words, dumb is exactly the right TERM value to use.
(Note there are modes that emulate terminals—see, for instance, M-x ansi-term—and they set TERM=eterm-color or similar, but they're designed to let you use Emacs as an xterm replacement for visual-mode shell commands, whereas M-x shell is designed to let you run shell commands while still interacting with the input and output in an Emacs-y way.)
When you choose a TERM value that isn't supported by termcap, you'll get the above error and some programs may get confused about what's happening (and some will refuse to run at all). If you select a full-featured TERM value like xterm instead, you'll get "line-noise" characters as the programs attempt to send formatting codes to a terminal emulator that isn't there.
You could probably get away with finding some termcap that was limited enough in capabilities that it won't bother you with noise too much, but if this is just to let you differentiate Emacs interactive shells from either Emacs non-interactive shells or non-Emacs interactive shells, there's a better choice.
This choice, in fact, isn't even sufficient. That's because this special shell script is loaded by both shell-mode and by TRAMP, so the above still wouldn't let you differentiate the two—you'd just get emacs in both cases instead of dumb!
So this is where the better choice comes in:
Using the INSIDE_EMACS environment variable
While, as you noted, the interactive shell and TRAMP both set TERM to dumb by default, they also set an environment variable INSIDE_EMACS.
Its existence (or not) alone is useful for your shell startup scripts, but its power for your use case lies in its value—which, for interactive (M-x shell) use, is something like 25.2.2,comint, but for TRAMP is 25.2.2,tramp.
So, to check for the three cases, here's what you can do (and what I personally have done myself in my ~/.zshrc for many years):
# Setup for all shells--Emacs or not, interactive or not, goes
# here
PATH=...
source $my_functions_file
# Now dumb terminals
if [[ "${TERM}" == "dumb" ]]; then
# Here put anything you want to run in any dumb terminal,
# even outside Emacs.
PATH=...
alias lsF='ls -F'
etc
# Now, just configs for shells inside Emacs
case ${INSIDE_EMACS/*,/} in
(comint)
do_comint_stuff
;;
(tramp)
do_tramp_stuff
;;
(term*)
# For M-x ansi-term, etc., you get a value like
# 25.2.2,term:0.96, but those shouldn't coincide with
# TERM being `dumb`, so warn....
echo "We somehow have a dumb Emacs terminal ${INSIDE_EMACS/*,/}" >&2
;;
("")
# Empty means we're $TERM==dumb but not in Emacs, do nothing
;;
(*)
# We shouldn't get here, so write a warning so we can
# figure out how else Emacs might be running a shell,
# but send it to stderr so that it won't break anything
echo "Something is wrong: INSIDE_EMACS is ${INSIDE_EMACS}" >&2
;;
esac
# finish shell setup for dumb now--the rest of the file will
# be skipped
return
fi
# Stuff for non-dumb, interactive visual, shells goes here
setup_prompt
setup_keybindings
etc
We don't reset TERM to a different value inside the case statement because dumb is exactly what it should be.
Note that above, in the (tramp) section of the case statement, you could do what you mentioned in your question—set TERM to something else just for TRAMP—but that would be a bad idea, since Emacs actually reads and acts on responses it gets from TRAMP shells, and the line noise would be an even bigger problem. TRAMP can do some really amazing things, but only when the shell output it's reading is in the format TRAMP expects.
(One final thing: using the code as above, with the INSIDE_EMACS checks nested instead the dumb terminal check, we don't have a single place to put code to be run in all Emacs-spawned shells regardless of type, including M-x ansi-term and its ilk. You could write a separate statement for that in your shell config... but that's exactly what ~/.emacs.d/init_${SHELLNAME}.sh is for, so probably a better choice if you need this for some reason.)
Is there any way to capture the texts on termianl screen inside a perl script. I know there are some functions like system,exec,backticks but the problem is that they execute commands FROM the script.For ex:- in terminal i write cd/ (or) ls,and after that i run my perl script which will read what was written on termianl screen(in this case, scipt will capture cd/ (or) ls-whichever was given to termianl). I came with one solution that by passing the commands which you wrote on termianl as a command line arguments to the script,but any other way???
Like this maybe:
history | perl -ne 'print $_'
As I understand it, in a situation where you've typed some stuff into a terminal like this:
[tai#littlerobot ~] echo "Hello"
Hello
[tai#littlerobot ~] perl myscript.pl
You want myscript.pl to be able to access the echo "Hello" part, and possibly also the Hello that was that command's output.
Perl does not provide such a feature. No programming language does or can provide such a feature because the process in which your script/program runs has no intrinsic knowledge about what happened in the same terminal before it was run. The only way it could access this text would be if it could ask the currently running terminal, which will have some record of this information (i.e. the scrollback buffer), even if it cannot distinguish between which characters in the text were typed by you, and which are output. However, I know of no terminal that exposes that information via any kind of public API.
So if you want myscript.pl to be able to access that echo "Hello", you'll need to pass it to your script. Piping history to your script (as shown by Mark Setchell in his answer) is one technique. history is a shell built-in, so it has as much knowledge as your shell has (which is not quite the same knowledge as your terminal has). In particular it can give you a list of what commands have been typed in this shell session. However, it cannot tell you about the output generated by those commands. And it cannot tell you about other shell sessions, so doing this in Perl is fairly useless:
my #history = `tcsh -c history`;
The last thing you could try (though it would be incredibly complicated to do) would be to ask the X server (or Windows if running on that operating system) for a screen shot and then attempt to locate which rectangle the current terminal is running in and perform OCR on it. This would be fraught with problems though, such as dealing with overlapping windows.
So, in summary, you cannot do this. It's nothing to do with Perl. You cannot do this in any programming language.
I usually think of UNIX pipes as a quick and dirty way to interact with the console, doing things such as:
ls | grep '\.pdf$' #list all pdfs
I understand that it's possible to use create named pipes using mkfifo and mknod.
Are named pipes still used significantly today, or are they a relic of the past?
They are still used, although you might not notice. As a first-class file-system object provided by the operating system, a named pipe can be used by any program, regardless of what language it is written in, that can read and write to the file system for interprocess communication.
Specific to bash (and other shells), process substitution can be implemented using named pipes, and on some platforms that may be how it actually is implemented. The following
command < <( some_other_command )
is roughly identical to
mkfifo named_pipe
some_other_command > named_pipe &
command < named_pipe
and so is useful for things like POSIX-compliant shell code, which does not recognize process substitution.
And it works in the other direction: command > >( some_other_command ) is
mkfifo named_pipe
some_other_command < named_pipe &
command > named_pipe
pianobar, the command line Pandora Radio player, uses a named pipe to provide a mechanism for arbitrary control input. If you want to control Pianobar with another app, such as PianoKeys, you set it up to write command strings to the FIFO file, which piano bar watches for incoming commands.
I wrote a MAMP stack app in college that we used to manage users in an LDAP database on a file server. The PHP scripts would write commands to a FIFO that a shell script running in launchd would read from and interact with the LDAP database. I had no idea what I was doing, so I don’t know if there was a better or more correct way to do it, but it worked great at the time.
Named pipes are useful where a program would expect a path to a file as an argument as opposed to being willing to read/write with stdin and stdout, though very modern versions of bash can get around this with < ( foo ) it is still sometimes useful to have a file like object which is usable as a pipe.
In Perl, how do I test if a file of open by another Perl program? I need the first program to be done before the second program can start.
alt text http://musicritics.com/wp/wp-content/uploads/2009/05/20061129morbo.gif
FILES DO NOT WORK THAT WAY!
But seriously, folks, advisory locks with flock are generally the best you can do. There's no way to guarantee that no other program wants to read or write a file at the same time as you.
You may be able to coordinate the two programs using flock: The first program would lock the file, and the second program would also try to acquire a lock on it, and it would block until the first program releases the lock.
Is flock() available on your system ? Otherwise, the two programs have be be synchronized, they can communicate thru a pipe or a socket, or via the presence/absence of a file.
Another direction if you are on a Unix-like system, could be use lsof output.
I assume having the first program starting the second one is not feasible.
In my experience, flock works fine on local systems on both Windows and Linux.
You could also, presumably, have the first program exec the second program when it's done processing the file.
If you are running on Windows, you could call CreateFile directly with a dwShareMode of 0.
According to MSDN:
Prevents other processes from opening a file or device if they request delete, read, or write access.
Win32API::File gives access to this call.
To specifically look for whether or not a file is open or in use, if you're on unix there is a wrapper to the lsof command to list open files: Unix::Lsof
If you're in Unix, you could also call fuser.
I might be misunderstanding the context and my comment may have limited usability in your case, but depending on what you are using the code for/on - Using serial queues to ensure that tasks to execute in a predictable order maybe an option. Your application (written in Perl) will need to explicitly create and manage the serial queues. For more details refer to the following link: GCD
It is generally advised not to use additional linux tools in a Perl code;
e.g if someone intends to print the last line of a text file he can:
$last_line = `tail -1 $file` ;
or otherwise, open the file and read it line by line
open(INFO,$file);
while(<INFO>) {
$last_line = $_ if eof;
}
What are the pitfalls of using the previous and why should I avoid using shell tools in my code?
thanx,
Efficiency - you don't have to spawn a new process
Portability - you don't have to worry about an executable not existing, accepting different switches, or having different output
Ease of use - you don't have to parse the output, the results are already in a usable form
Error handling - you have finer-grained control over errors and what to do about them in Perl.
It's better to keep all the action in Perl because it's faster and because it's more secure. It's faster because you're not spawning a new process, and it's more secure because you don't have to worry about shell meta character trickery.
For example, in your first case if $file contained "afilename ; rm -rf ~" you would be a very unhappy camper.
P.S. The best all-Perlway to do the tail is to use File::ReadBackwards
One of the primary reasons (besides portability) for not executing shell commands is that it introduces overhead by spawning another process. That's why much of the same functionality is available via CPAN in Perl modules.
One reason is that your Perl code might be running in an environment where there is no shell tool called 'tail'.
It's a personal call depending on the project:
Is it going to be always used in shell environments with tail?
Do you care about only using pure Perl code?
Using tail? Fine. But that's really a special case, since it's so easy to use and since it is so trivial.
The problem in general is not really efficiency or portability, that is largely irrelevant; the issue is ease of use. To run an external utility, you have to find out what arguments it accepts, write code to transform your program's data structures to that format, quote them properly, build the command line, and run the application. Then, you might have to feed it data and read data from it (involving complexity like an event loop, worrying about deadlocking, etc.), and finally interpret the return value. (UNIX processes consider "0" true and anything else false, but Perl assumes the opposite. foo() and die is hard to read.) This is a lot of work to do, and that's why people avoid it. It's much easier to create an instance of a class and call methods on it to get the data you need.
(You can abstract away processes this way; see Crypt::GpgME for example. It handles the complexity associated with invoking gpg, which would normally involve creating multiple filehandles other than STDOUT, STDIN, and STDERR, among other things.)
The main reason I see for doing it all in Perl would be for robustness. Your use of tail will fail if the filename has shell metacharacters or spaces or doesn't exist or isn't accessible. From Perl, characters in the filename aren't an issue, and you can distinguish between errors in accessing the file. Sometimes being robust is more important than speedy coding and sometimes it's not.