Tag: Unix

Env for scripts interpreter searching

Posted by – February 15, 2012

#!/usr/bin/env bash
Probably the most common use of env is to find the correct interpreter
for a script, when the interpreter may be in different directories on
different systems.  The following example will find the `perl’ inter-
preter by searching through the directories specified by PATH.
1.  #!/usr/bin/env perl
One limitation of that example is that it assumes the user’s value for
PATH is set to a value which will find the interpreter you want to exe-
cute.  The -P option can be used to make sure a specific list of directo-
ries is used in the search for utility.  Note that the -S option is also
required for this example to work correctly.
2. #!/usr/bin/env -S -P/usr/local/bin:/usr/bin perl
The above finds `perl’ only if it is in /usr/local/bin or /usr/bin.  That
could be combined with the present value of PATH, to provide more flexi-
bility.  Note that spaces are not required between the -S and -P options:
3. #!/usr/bin/env -S-P/usr/local/bin:/usr/bin:${PATH} perl

#!/usr/bin/env bash
Probably the most common use of env is to find the correct interpreter     for a script, when the interpreter may be in different directories on     different systems.  The following example will find the `perl’ inter-     preter by searching through the directories specified by PATH.
1.  #!/usr/bin/env perl     One limitation of that example is that it assumes the user’s value for     PATH is set to a value which will find the interpreter you want to exe-     cute.  The -P option can be used to make sure a specific list of directo-     ries is used in the search for utility.  Note that the -S option is also     required for this example to work correctly.
2. #!/usr/bin/env -S -P/usr/local/bin:/usr/bin perl
The above finds `perl’ only if it is in /usr/local/bin or /usr/bin.  That     could be combined with the present value of PATH, to provide more flexi-     bility.  Note that spaces are not required between the -S and -P options:
3. #!/usr/bin/env -S-P/usr/local/bin:/usr/bin:${PATH} perl

Env

Posted by – February 15, 2012

#!/usr/bin/env bash
Probably the most common use of env is to find the correct interpreter
for a script, when the interpreter may be in different directories on
different systems.  The following example will find the `perl’ inter-
preter by searching through the directories specified by PATH.
1.  #!/usr/bin/env perl
One limitation of that example is that it assumes the user’s value for
PATH is set to a value which will find the interpreter you want to exe-
cute.  The -P option can be used to make sure a specific list of directo-
ries is used in the search for utility.  Note that the -S option is also
required for this example to work correctly.
2. #!/usr/bin/env -S -P/usr/local/bin:/usr/bin perl
The above finds `perl’ only if it is in /usr/local/bin or /usr/bin.  That
could be combined with the present value of PATH, to provide more flexi-
bility.  Note that spaces are not required between the -S and -P options:
3. #!/usr/bin/env -S-P/usr/local/bin:/usr/bin:${PATH} perl

#!/usr/bin/env bash
Probably the most common use of env is to find the correct interpreter     for a script, when the interpreter may be in different directories on     different systems.  The following example will find the `perl’ inter-     preter by searching through the directories specified by PATH.
1.  #!/usr/bin/env perl     One limitation of that example is that it assumes the user’s value for     PATH is set to a value which will find the interpreter you want to exe-     cute.  The -P option can be used to make sure a specific list of directo-     ries is used in the search for utility.  Note that the -S option is also     required for this example to work correctly.
2. #!/usr/bin/env -S -P/usr/local/bin:/usr/bin perl
The above finds `perl’ only if it is in /usr/local/bin or /usr/bin.  That     could be combined with the present value of PATH, to provide more flexi-     bility.  Note that spaces are not required between the -S and -P options:
3. #!/usr/bin/env -S-P/usr/local/bin:/usr/bin:${PATH} perl

Using tar together with gzip

Posted by – September 22, 2011

How can I extract a tar.gz or .tgz file?
Files with extension tar.gz or .tgz are tar files compressed with gzip. On Unix extract them with:

gunzip < file.tar.gz | tar xvf –
gunzip < file.tgz    | tar xvf –
Can gzip compress several files into a single archive?
Not directly. You can first create a tar file then compress it:

tar cvf –  filenames | gzip > file.tar.gz

ssh login without enter password/passphrase every time.

Posted by – July 21, 2011


http://www.ibm.com/developerworks/library/l-keyc2/
http://www.gentoo.org/doc/en/keychain-guide.xml
http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-ssh-hack

Keychain:
http://docs.funtoo.org/wiki/Keychain

Bash Colors

Posted by – June 20, 2011

Bash Color Escape Codes

Echo (echo -e) the following escape codes inside \e[ESCCODEm to colorize text in Bash:

  • Black 0;30
  • Dark Gray 1;30
  • Blue 0;34
  • Light Blue 1;34
  • Green 0;32
  • Light Green 1;32
  • Cyan 0;36
  • Light Cyan 1;36
  • Red 0;31
  • Light Red 1;31
  • Purple 0;35
  • Light Purple 1;35
  • Brown 0;33
  • Yellow 1;33
  • Light Gray 0;37
  • White 1;37

Make sure to use echo -e to enable interpretation of backslash escapes:

bash$ echo -e "This is red->\e[00;31mRED\e[00m"

Remove Color

Echo \e[00m to remove text color modifications:

bash$ echo -n '\e[00m'

Calling Qt Functions From Unix Signal Handlers

Posted by – May 18, 2010

Home · All Classes · All Functions · Overviews

Calling Qt Functions From Unix Signal Handlers

Refers to:
http://doc.qt.nokia.com/4.6/unix-signals.html
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_04.html#tag_02_04_01
http://doc.qt.nokia.com/4.6/qsocketnotifier.html
http://doc.qt.nokia.com/4.6/platform-specific.html
You can’t call Qt functions from Unix signal handlers. The standard POSIX rule applies: You can only call async-signal-safe functions from signal handlers. See Signal Actions for the complete list of functions you can call from Unix signal handlers.

But don’t despair, there is a way to use Unix signal handlers with Qt. The strategy is to have your Unix signal handler do something that will eventually cause a Qt signal to be emitted, and then you simply return from your Unix signal handler. Back in your Qt program, that Qt signal gets emitted and then received by your Qt slot function, where you can safely do whatever Qt stuff you weren’t allowed to do in the Unix signal handler.

One simple way to make this happen is to declare a socket pair in your class for each Unix signal you want to handle. The socket pairs are declared as static data members. You also create a QSocketNotifier to monitor the read end of each socket pair, declare your Unix signal handlers to be static class methods, and declare a slot function corresponding to each of your Unix signal handlers. In this example, we intend to handle both the SIGHUP and SIGTERM signals. Note: You should read the socketpair(2) and the sigaction(2) man pages before plowing through the following code snippets.

[cpp]
class MyDaemon : public QObject
{
Q_OBJECT

public:
MyDaemon(QObject *parent = 0, const char *name = 0);
~MyDaemon();

// Unix signal handlers.
static void hupSignalHandler(int unused);
static void termSignalHandler(int unused);

public slots:
// Qt signal handlers.
void handleSigHup();
void handleSigTerm();

private:
static int sighupFd[2];
static int sigtermFd[2];

QSocketNotifier *snHup;
QSocketNotifier *snTerm;
};
[/cpp]

In the MyDaemon constructor, use the socketpair(2) function to initialize each file descriptor pair, and then create the QSocketNotifier to monitor the read end of each pair. The activated() signal of each QSocketNotifier is connected to the appropriate slot function, which effectively converts the Unix signal to the QSocketNotifier::activated() signal.

[cpp]
MyDaemon::MyDaemon(QObject *parent, const char *name)
: QObject(parent,name)
{
if (::socketpair(AF_UNIX, SOCK_STREAM, 0, sighupFd))
qFatal("Couldn’t create HUP socketpair");

if (::socketpair(AF_UNIX, SOCK_STREAM, 0, sigtermFd))
qFatal("Couldn’t create TERM socketpair");
snHup = new QSocketNotifier(sighupFd[1], QSocketNotifier::Read, this);
connect(snHup, SIGNAL(activated(int)), this, SLOT(handleSigHup()));
snTerm = new QSocketNotifier(sigtermFd[1], QSocketNotifier::Read, this);
connect(snTerm, SIGNAL(activated(int)), this, SLOT(handleSigTerm()));


}
[/cpp]

Somewhere else in your startup code, you install your Unix signal handlers with sigaction(2)

[cpp]
static int setup_unix_signal_handlers()
{
struct sigaction hup, term;

hup.sa_handler = MyDaemon::hupSignalHandler;
sigemptyset(&hup.sa_mask);
hup.sa_flags = 0;
hup.sa_flags |= SA_RESTART;

if (sigaction(SIGHUP, &hup, 0) > 0)
return 1;

term.sa_handler = MyDaemon::termSignalHandler;
sigemptyset(&term.sa_mask);
term.sa_flags |= SA_RESTART;

if (sigaction(SIGTERM, &term, 0) > 0)
return 2;

return 0;
}
[/cpp]

In your Unix signal handlers, you write a byte to the write end of a socket pair and return. This will cause the corresponding QSocketNotifier to emit its activated() signal, which will in turn cause the appropriate Qt slot function to run.

[cpp]
void MyDaemon::hupSignalHandler(int)
{
char a = 1;
::write(sighupFd[0], &a, sizeof(a));
}

void MyDaemon::termSignalHandler(int)
{
char a = 1;
::write(sigtermFd[0], &a, sizeof(a));
}
[/cpp]

In the slot functions connected to the QSocketNotifier::activated() signals, you read the byte. Now you are safely back in Qt with your signal, and you can do all the Qt stuff you weren’tr allowed to do in the Unix signal handler.

[cpp]
void MyDaemon::handleSigTerm()
{
snTerm->setEnabled(false);
char tmp;
::read(sigtermFd[1], &tmp, sizeof(tmp));

// do Qt stuff

snTerm->setEnabled(true);
}

void MyDaemon::handleSigHup()
{
snHup->setEnabled(false);
char tmp;
::read(sighupFd[1], &tmp, sizeof(tmp));

// do Qt stuff

snHup->setEnabled(true);
}
[/cpp]