Tag Info

New answers tagged

1

This is a repost of my answer to a similar question: The ZIP file format includes a directory (index) at the end of the archive. This directory says where, within the archive each file is located and thus allows for quick, random access, without reading the entire archive. This would appear to pose a problem when attempting to read a ZIP archive through a ...


2

You need to combine the output of STDERR and STDOUT prior to piping it to logger. Try this instead: /home/dirname/application_name -v 2>&1 | logger & Example $ echo "hi" 2>&1 | logger & [1] 26818 [1]+ Done echo "hi" 2>&1 | logger $ sudo tail /var/log/messages Apr 12 17:53:57 greeneggs saml: hi You can ...


0

@Patrick points out in the comments below that access to these files requires a non-default kernel compile-time option. I was not aware of this having only now discovered them at all. Though I do know that my kernel package was installed via package-manager and so it must be included in the default build at least for one distribution - so your mileage may ...


3

The /proc file system will list exactly this information: $ ls -l /proc/self/fd total 0 lrwx------ 1 michas users 1 Apr 6 04:44 0 -> /dev/pts/0 lrwx------ 1 michas users 1 Apr 6 04:44 1 -> /dev/pts/0 lrwx------ 1 michas users 1 Apr 6 04:44 2 -> /dev/pts/0 lr-x------ 1 michas users 1 Apr 6 04:44 3 -> /proc/6934/fd $ ls -l /proc/self/fd ...


2

Just so you know - you're not limited to a single command per |pipe: this happens | then this | { then ; all of ; this too ; } | before this All of those processes are invoked at the same time - but they all wait on the |pipe before them before actually doing anything - so long as they read the |pipe at all, that is. So, if you need to evaluate a variable ...


3

As other people have answered, > is not a command, but rather a redirect operator. However, the term 'redirection operator' doesn't specifically refer to the >, but a number of different possible redirection operators. The dash man page lists the following as redirection operators: < > >| << >> <& >& <<- ...


0

> redirects output to a file (or device) overwriting anything already existing there >> redirects output to a file (or device) appending to anything already existing there < directs data from a file (or device) to a program or device << a here document


8

sudo supports this. $ echo hello world | sudo cat SUDO password: hello world The difference being that sudo asks for your user password, not the root (target user) password. However if you so desire, you can change this behavior with the targetpw (or runaspw or rootpw) directive in sudoers.conf. However reading what you're trying to do, while this ...


26

> is a redirection operator. Note that using > to redirect to a regular file will overwrite what is already there, unless noclobber is set. >> will append to the end of the file.


46

> is not a command but a file descriptor redirection. This means that the shell parses this assignment, removes it from the command line and changes the environment for the new process in which it is started. The new process does not notice this part of the command line. That's the reason why you can put it everywhere: At the beginning, at the end or in ...


0

This is a problem that has long been solved with syslog (in all it's variants) but there are two tools that would solve your particular problem with a minimum of effort. The first, more portable but less versatile solution is logger (a must have for any administrators toolbox). It is a simple utility that copies standard input to syslog. (passing the buck, ...


1

If I'm understanding correctly, tee seems like a reasonable approach: $ ./myapp-that-echoes-the-date-every-second | tee log > /dev/null & [1] 20519 $ head log Thu Apr 3 11:29:34 EDT 2014 Thu Apr 3 11:29:35 EDT 2014 Thu Apr 3 11:29:36 EDT 2014 $ > log $ head log Thu Apr 3 11:29:40 EDT 2014 Thu Apr 3 11:29:41 EDT 2014 Thu Apr 3 11:29:42 EDT ...


7

Another form of this problem occurs with long running applications whose logs are periodically rotated. Even if you move the original log (e.g., mv log.txt log.1) and replace it immediately with a file of the same name before any actual logging occurs, if the process is holding the file open, it will either end up writing to log.1 (because that may still be ...


1

As fast solution you can use a log with rotation (daily rotation for example): date=date +%Y%m%d LOGFILE=/home/log$date.log and redirect logging to it ./my_app >> log$date.log


0

Here's one way to test if a command will accept stdin or not. Mind you, this is hardly exhaustive: % { wc ; cat ; } <<INTEST nope INTEST > 1 1 5 % { cd ; cat ; } <<INTEST nope INTEST > nope


1

For the specific example you've cited, you need to use command substitution: cd -P -- "$(dirname -- "$(which w3af)")" for the simple reason that cd doesn't take input via STDIN. It accepts only parameters. Moreover, which command would produce a path to a file not a directory.


1

Close fd3 twice because you fork two subshell in script, each subshell is inherited and copy parent's file descriptor. Close fd3 in each subshell doesn't affect others (and the parent, too). So the comment line is very unclear and causes misleading. If you want to redirect only stder to pipe, you can use process substitution: ls -l 2> >(grep bad) ...


0

All redirections in the |pipeline affect the specific processes they're applied to. Unless you specifically group the processes therein, two redirections like >&3 3>&- will close &1, not save it. You can only have one direction for the file unless some process duplicates it for you. This is what you want to do, I think: ls -l 2>&- | ...


3

Neither ls nor grep need anything open on their fd 3 (they don't use that fd), so it's better practice to close it (release the resources you don't need). We only use that fd 3 to be able to restore ls stdout to the original one (before executing ls). Remember that in a pipe line, all commands run concurrently in their own process. Redirections apply for ...


0

I'm fairly certain your problem is that the -interactive operand expects a terminal and backgrounding the process cuts off its stdin/stdout. Consider using nc ... -e to invoke the shell upon connection. The link there is a handy little netcat pdf cheatsheet. For -e see BACKDOORS. You'll probably need a GNU build of nc to use it - else you'll want to ...


0

Consider using tcpdump instead. The only requirement is that you must be root user. No one else should have privileges to listen in on any tcp connections, not even ones you've started yourself. tcpdump can capture every packet and then you can review it with tools like wireshark. It has many extra features available, and can even be left unattended ...


4

The probem because cron run task with sh. &> is a shortcut to redirect both stderr and stdout to the same file in bash, not in sh. In sh, your command: cat /home/dbk/.bash_aliases &> /home/dbk/Desktop/junk meaning run two commands separately: Run cat /home/dbk/.bash_aliases in background "cat /home/dbk/.bash_aliases &" Truncate the ...


5

From bash manpage: Duplicating File Descriptors The redirection operator [n]<&word is used to duplicate input file descriptors. If word expands to one or more digits, the file descriptor denoted by n is made to be a copy of that file descriptor. If the digits in word do not specify a file ...



Top 50 recent answers are included