Linux systems provide a nice tool (script) that can log terminal stdout data in a file. It has the following format:
To turn on logging: script [options] [filename]
To turn off logging: exit
I'm looking for an identical utility for windows console and powershell (Or any native windows support for logging the entire session).
Note: Please don't suggest redirection.
I believe you're looking for Start-Transcript.
Keep in mind: It won't work in the ISE. Don't forget Stop-Transcript at the end of your script!
Related
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
I'm using PuTTY to connect to a zOS mainframe (running USS, IBM's Unix-compatible software) and I'd like to download a hex dump (using od) of a file without making a copy of it on the filesystem. Is there a way that I can save or pipe stdout (through PuTTY) directly to a file on my (Windows XP) client?
You could configure session logging for your PuTTY session, as per the documentation. Then just run od on the server, wait until it finishes, and then close your log file. You'll need to trim the cruft at the beginning and end (because it has your whole session), but you should end up with what you want.
Note that upon inspection that documentation link may be for an older version of PuTTY, so YMMV but I'm sure that more recent versions also support session logging.
If you were to install a command-line ssh tool (e.g., running OpenSSH under Cygwin), you could then do the standard "ssh hostname command > file" sort of redirection.
I have an update function in my app - it downloads and verifies the installer (a setup.exe, created with NSIS). To actually kick off the update, I have simply been doing:
QString path = .. absolute path to the downloaded file ...
QProcess::startDetached(path, QStringList());
This works fine on XP - but on Vista and Win7, nothing happens once the download completes. If I browse to the downloaded update and run it manually, it works fine. I assume what's happening is that UAC is blocking the installer at CreateProcess time, but this is where my knowledge runs out.
Additional complication - when I'm running a debug build from the command line, the steps above work - I get the UAC prompt and can run the installer. It's the release builds, started form the start menu/shortcut, which have the issue - I assume there's a difference in the auth token when running from a command shell.
You can also use
QDesktopServices::openUrl(QUrl::fromLocalFile(path));
Might be surprising and counterintuitive, but it works and is more cross-platform
If you are not admin and you call CreateProcess() on a .exe with a "Vista" manifest (or no manifest, but a .exe that windows detects as an installer (This includes NSIS)) the call fails, you need to use ShellExecute[Ex](). ShellExecute will trigger UAC prompt if required...
This seems to be a Qt bug, see QTBUG-9761 , the correct workaround is to use ShellExecute with lpOperation set to runas.
Another alternative is to prepend your execution with cmd.exe /C. This effectively routes your execution through the shell, so you do get the UAC prompt. The downside is that if your process fails you probably won't get as much information had you gone through ShellExecute[Ex], but on the plus side you will get all the facilities of QProcess that you miss if you use QDesktopServices::openUrl, where you have no idea if things worked or not.
i am working on unix.
i want to write a shell script which will check for a file called "temp_file.txt" on windows
and then execute some commands.
is this possible?
how could we connect to the windows and go to a specific directory and check for a file?
Share the directory on the Windows machine using the "regular" Windows file sharing facilities. On the Linux side, you have two options:
Use smbclient to connect to the Windows machine and check if the file exists or
Use smbmount to mount the shared directory into your Linux file system and check file existence using "standard" Linux commands (e.g. test).
The exact implementation details will depend on the scripting language that you use, but your pseudo-code will look something like this:
loop:
check if file exists
if yes: do something useful
sleep for some reasonable time
(I am assuming that you want to execute the commands on the Linux machine.)
If you're using Linux (you specify that you're using Unix, but not what variant), check out the inotify API --- this will allow you to set up event responders for filesystem events (much more efficient than polling).
From a shell script, you can use the inofitywait command --- see http://linux.die.net/man/1/inotifywait for more information.
you could set up SSH on Windows and then write a script on Unix using the SSH client to connect to Windows and execute the command. The alternative, if you can afford to, it to write a windows batch, and execute your command on Windows itself. Or you can turn on Windows terminal services, and use telnet protocol from Unix to issue the command. Programming languages that support telnet includes Perl (Net::Telnet) and Python(telnetlib)
As ghostdog74 suggested, ssh is your best bet. You can run something like (I assume you have Cygwin or SFU installed)
ssh "[ -e $file ] && do_something.sh" > do_something.log
If your command logs to stdout, you get the log on your Linux box as well.
If you set up private key authentication, it gets even better.
I need any tool or IDE environment to debug and test the vb scripts code. Please suggest any free ones. My vb scripts are standalone (vbs extenstion).
VBSEdit
Not free, but has an unlimited trial period with a nag screen.
Sadly not free....How to debug Windows Script Host, VBScript, and JScript files
I think you'll have a hard time finding a free tool that supports real VBS debugging. But I've used this "poor man's technique" in the past. Create a variable at the beginning of your script
blnDebug=False
Then throughout your script add lines to echo what the script is doing or the value of different variables:
if blnDebug Then wscript.echo "Now starting script strFoo=" & strFoo
When you set blnDebug=True then all your debug messages will be written to the console (I always use CScript when running this). By adding these debug messages as you write your script, you can have debugging available simply by changing the bldDebug value.
Certainly commercial editors like PrimalScript include a debugger. SAPIEN also has a standalone debugger, http://www.primalscope.com/, that while not free is a relatively inexpensive option. You can download an eval copy to try it out.
There is a really old tool called Script Debugger for Windows NT 4.0 and Later. It is designed for VBScripts running in web pages but you can attach it to a vbs script easy enough.
You can download it from here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=2f465be0-94fd-4569-b3c4-dffdf19ccd99&displaylang=en
The name says NT 4.0 I know but I am currently running it on Windows 7 x64 and hod no problems opening the debugger.
Simply install the above tool then run your script from the commandline like:
wscript.exe myscript.vbs //d //x
Once the debugger opens you can step through code and even open a command window where you can check variable values by typeing ? Varname.