Showing posts with label unix. Show all posts
Showing posts with label unix. Show all posts

Friday, April 19, 2013

Connecting from Mac OS X to Ubuntu

Prerequisites

MacOS

  • Install a VNC client. I tried Chicken of the VNC.
  • ssh client (normally available by default in Mac OS). You'll need this if you need to bring up the VNC server from the client (i.e., Mac OS)
  • You would need to know the IP of the computer. This may be problematic if the computer is issued a dynamic IP.

Ubuntu

  • Get a VNC server. Using apt you can try to install x11vnc.
  • $ sudo apt install x11vnc

Setup

  • Assuming that the VNC server is not up, you would need to bring it up from Mac OS. You would need the IP of the remote computer. You would also need to bring up a tunnel so that your VNC client can just connect to a local port at your box. Bring up a terminal and send the command:
  • $ ssh userXXX@170.198.142.143 -L 5901:localhost:5901
  • Start VNC server
  • $ x11vnc -safer -localhost -nopw -once -display :0 -rfbport 5901

Startup VNC

  • Bring up the VNC client at your Mac
  • Configure it to connect to your LOCALHOST (if  you created a tunnel, or if not use the IP of the remote Ubuntu computer).
  • Also make sure you configured the port properly.
  • Make sure as well that the display setting is as configured.

Friday, January 25, 2013

Sending Email via the UNIX Bash Shell


You would need to have sendmail and mailx packages installed.

With these, you can issue the following command to send an email via the shell:

$ echo "test" | mailx -a ./file.txt -s "subject2" abc@email.com

The above command pipes the string "test" to the mailx command which constructs an email for abc@email.com with the subject, "subject2" and an attachment, "file.txt".
Alternatively, you can enter interactive mode with the mailx command:

$ mailx -a ./file.txt -s "subject2" abc@email.com

The shell then lets you type in your message. To exit the interactive mode, you just enter a new line and type in '.'.

If sending a binary file, it's always best to encode it first:

$ uuencode file.bin file.bin | mailx -s "subject2" abc@email.com


Friday, January 18, 2013

Unix Shell stderr and stdout redirections


This has always confused me. So I'll try to recapitulate what I understand in this mini-blog for my future reference.

In a Unix shell, 0 stands for stdin, 1 stands for stdout while 2 stands for stderr.

You can redirect stderr to stdout if you append this to your Unix command:

2>&1

Corollary, you can redirect stdout to stderr (which do not usually happen) by appending this otherwise:

1>&2

By default, when you redirect a stream, it redirects stdout. Which means the this command will log stdout to the the file (but not stderr):

$ echo "test string" >test.log

Building on this, if we want not only stdout but also stderr to the directed to test.log we issue this command:

$ echo "test string" >test.log 2>&1

The command reads from left to right (and the sequence is important as the first redirection takes precedence over the later redirection specification). And it should read: "redirect stdout to test.log, then redirect the stderr to the same place stdout is going (which is test.log)."

Now, in some cases, the sequence does not "seem" make any difference but in fact there's a subtle nuance introduced by the sequence like in doing so:

$ echo "test string" 2>&1 >test.log 

In the above, it reads: "redirect stderr to the same place stdout is going (which is the console), then redirect stdout to test.log (but not stderr)." The net effect is that stderr is redirected to console but stdout is directed to test.log. The above is made more explicit by the equivalent command:

$ echo "test string" 2>&1 1>test.log 

Now consider these two commands:

$ echo "test string" >/dev/null 2>&1
$ echo "test string" 2>&1 >/dev/null

The first reads: "redirect stdout to /dev/null (meaning discard the bytes streamed to stdout), then redirect stderr to the same place stdout is going (which is now /dev/null)." The end effect is that both stdout and stderr is discarded.

The second reads: "redirect stderr to the same place stdout is going (which is the console), then redirect stdout to /dev/null (meaning discard the bytes streamed to stdout)." The end effect is that whilst stderr is printed on the console, stdout is discarded.

One link that really seems helpful is this: http://wiki.bash-hackers.org/howto/redirection_tutorial