I'm running the tcl(which has expect script) using perl with,
system("C:/Tcl/bin/tclsh86 C:/Users/sysadmin/desktop/expect.tcl");
It's not executing the all commands in the script, but its working fine on ubuntu.
What command should i use to run this completely using perl on Windows?
On Unix Expect works using virtual terminals. By contrast, Expect on Windows uses the debugging subsystem. (There's nothing like virtual terminals on Windows.) This has the down-side that programs that are marked as being impossible to debug (i.e., some system programs, notably including telnet.exe though ftp.exe might also be on that list) cannot be automated by Expect at all. The OS just refuses to let Expect connect to the process.
Is this what is happening to you? I can't tell from the minimal information you've given, but it is by far the most common reason for problems with porting an Expect script between platforms (once you've taken into account mundane things like different paths and programs that just aren't there on all platforms).
The up-side is that both Tcl and Perl are quite capable of talking directly to anything that you'd use telnet or ftp to talk to (as both are entirely proficient at TCP/IP). In fact, both are probably better at doing it natively than anything you'd likely achieve through use of Expect.
Related
The question I'm asking is a bit unclear, I think it's a bit hard to explain it with only one line. Here's my situation: I have a Bitbucket repertory which is cloned in both an Linux environment and Windows environment. The problem I have is:
1- I need to read and write from files and the paths to the different locations must be changed every time I commit and push. Hence, if I was working on Windows and made a push, when I go back to Linux and need to pull and change the paths I used.
2- I'm running selenium with Python. In order to make it work on my Linux serverless machine, I need to create a virtual display with pyvirtualdisplay library. Hence, some code that needs to be executed on my Linux machine must not be executed on my Windows machine.
So the problem I got is if I work on my Windows machine, I need to comment out the lines that creates the virtual display.
These two problems takes me a lot of time, because everytime I pull in a different machine, I can't directly work on the code, but have to change the code first.
Pretty simple. What you are looking for is to import the 'os' module.
import os
Then you can get the "name" of the current running Operating System by checking: os.name.
You can then base if or case statements, or however you want to manage your code, on what OS is reported.
To be clear, I would wrap the code I want to run only in a certain environment in an if statement that determines which OS is running and runs the appropriate code block based on the result.
if [[ os.name == "nt" ]]; then
;do Windows stuff
else
;do linux stuff
fi
Additional Note! That was psuedocode based on general Bash scripting.
This is Python psuedocode:
if os.name == "nt":
; Do Windows Stuff
else:
; Do Linux Stuff
Your first issue can be solved by handling the paths in a configuration file instead of hard-coding them in the program itself (and possibly using the pathlib or os.path modules for the actual path manipulations), then telling git to ignore the config file. You can then create appropriate configurations on each system, and git won't bother them at all.
Your second issue can be solved by using any of the various methods Python gives you to figure out what OS you're running on, and then using simple conditional statements to match on them. In theory, you could do the same for the paths, but it really is better in the long run to get in the habit of properly separating runtime configuration like that from program logic. Options for this include:
os.name: Contains posix, nt, or java, which identifies what type of OS you're on. java for Jython, nt for Windows,posix` for pretty much everything else. Useful when you just care about certain low-level OS semantics.
sys.platform: Contains a generic name for the underlying OS ABI. win32 for Windows, darwin for macOS, linux for Linux, and the name of the OS for other UNIX variants. This lets you check for particular underlying platforms, and is generally what you should use for conditional code that only runs on one platform. Make sure to always check this with a construct like sys.platform.startswith('X'), as some platforms and Python implementations include version info after the OS name.
platform.system(): Similar to sys.platform, except that the returned string is more user-friendly (Windows for Windows, Linux for Linux, etc), and it returns an empty string if it can't figure out what OS you're on. Useful for displaying the OS to the user, but not for doing conditionals (because it's free-form and may not always return useful information).
I have a Perl script I wrote for Linux. Now I'd like run it on AIX and Solaris (each one separately). Will I have to compile them (I prefer not to provide my users the uncompiled script).
Do I necessarily need AIX or Solaris machines to compile them?
If you have written your script such that it isn't using any platform specific features or commands, it should be fully portable. Refer to perlport for some more detail. Within Unix you're generally OK, but AIX is a bit of an odd Unix.
But in terms of compiling? Perl doesn't usually "compile" in the conventional sense. If you are compiling it into a binary executable, then this will be platform specific - you can occasionally 'get away' with a binary from Solaris/x86 running on Linux/x86, but it's better to assume not.
So yes, you will need to "compile" it on your specific architecture.
I would suggest that you don't actually need to though - perl is a scripting language, and script are plain text. Let their local installations of perl deal with the 'compiling' bit, and stop worrying about it. You honestly don't gain very much trying to compile perl anyway - at best it's an crude and trivial form of obfuscation.
Have a look at perlcompile to get a better understanding of this process.
Looking to execute a perl script on a remote machine via a Perl script. Appears one option is to use system() function and create an ssh key so the password is not required. Which leads me to the focus of this question, the other option appears to be to install and run one of these perl modules:
Net::SSH
Net::SSH2
Net::OpenSSH
Besides the protocol used, what else should I be comparing with these Perl modules?
The Net::OpenSSH documentation has a section describing the pros and cons of each. Here are some excerpts related to the ones you are asking about, but the documentation lists more:
Net::SSH is just a wrapper around any
SSH binary commands available on the
machine. It can be very slow as they
establish a new SSH connection for
every operation performed.
Net::SSH2 is much better than
Net::SSH::Perl, but not completely
stable yet. It can be very difficult
to install on some specific operative
systems and its API is also limited,
in the same way as Net::SSH::Perl.
Net::OpenSSH has a very perlish
interface. Most operations are
performed in a fashion very similar to
that of the Perl builtins and common
modules (i.e. IPC::Open2).
However, choice of platform may limit your options.
On the other hand, Net::OpenSSH does
not work on Windows, not even under
Cygwin.
Granted, the list is biased towards Net::OpenSSH, but it gives you an idea of the major differences between the modules.
Sometimes I see people use http://codepad.org as a way to quickly run/test their Perl snippets (it supports doing that with a wide variety of languages, from C to Scheme to Perl).
It's pretty obvious that there must be some limitations as to what code/features can be tested with codepad - does anyone know what those limitations are for Perl runner?
I'll get the ball rolling on my own observation: not every CPAN module is available :(
Mostly based on their "about" page:
codepad only supports Perl 5.8.0
Presumably, like any Perl install, not every module (CPAN or otherwise) is present.
As a specific example, List::MoreUtils is missing.
As a sub-limitation, they seem to run on Linux. So any Windows specific modules would certainly be out.
It's in a chroot jail with system calls restrictions. Among other things this seems to prevent file creation (my snippets creating files in a current directory or /tmp both errored out, as well as File::Temp calls)
codepad code is executed on a virtual machine. Behind firewalls. And buried in a bunker. So certain functionality is probably disabled - especially networking/internet one. The exact "about" quote is:
The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.
The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.
It's easier to just run Perl code locally. It's easy to install multiple versions of Perl and to track separate module repositories. It's also not hard to run just about any operating system you want in a virtual machine. Why you'd need anyone's else's service to do what you can do better yourself is beyond me.
We were just today discussing it, so I went on a little search but found nothing, zip, nada.
What is the future of ms's cmd shell? Do they intend to replace it completely with powershell in the future versions of windows, or just ship powershell as a parallel alternative ?
Does anyone have any links, articles, ... whatever regarding the above mentioned, cause I haven't been able to mind ms's stand regarding.
The latest build of Windows 7 has the two shells separately. I believe they won't replace the good-ol' cmd.exe. They need it mainly for compatibility reasons. A lot of programs call cmd /c, and replicating the exact same mechanism for powershell would be a duplication of effort. So, I suppose the cmd.exe remains.
cmd.exe is not going anywhere (it's far too widely used).
However, I don't think you'll be seeing any enhancements to it (not that they've been burning through them anyway).
Powershell is extremely good at doing complex tasks. However it is harder to learn and it runs much, much slower.
CMD will remain because you can run batch files and command line ops EXTREMELY quickly. Additionally it is extremely inexpensive to pop up a command shell and execute a command.
Imagine how many login scripts would break if they removed cmd.exe? Even if Powershell could run all cmd commands seamlessly (which it can't), login scripts running under Powershell would be far too slow during user login, as you would need to wait while .NET loaded up as well.
I once heard of a Citrix Admin who converted his login scripts to Powershell and then quickly realised that this was a bad idea.