Todd A. Jacobs | 2 May 2009 13:35
Favicon

New script: pdf_email_extractor.sh

#!/bin/bash

##
## Name:
##      pdf_email_extractor.sh
##
## Version:
##      $Revision: 1.4 $
##
## Purpose:
##      Extract email addresses from PDF files.
##
## Usage:
##      pdf_email_extractor.sh [-e <email>] [-p <parser>] [-f <flags>] [-r] <files>
##      pdf_email_extractor.sh [-h|-u]
##
## Options:
##      -e = destination email address for reports
##      -p = parser to convert PDF to text
##      -f = parser flags
##      -r = send email report with summary data
##      -h = display help
##      -u = show usage
##
## Errorlevels:
##      0 = Success
##      1 = Failure
##      2 = Other
##
## Caveats:
(Continue reading)

Todd A. Jacobs | 4 May 2009 02:17
Favicon

Re: New script: pdf_email_extractor.sh

Lots of ongoing patches and updates (I'm up to v1.6 already), so you can
always catch the latest and greatest here:

    http://codegnome.org/scripting/showscript.php?script=pdf_email_extractor.sh

Please to enjoy. :)

--

-- 
"Oh, look: rocks!"
	-- Doctor Who, "Destiny of the Daleks"
Todd A. Jacobs | 19 May 2009 21:42
Favicon

The <> redirector

I found this in the bash manual:

    3.6.10 Opening File Descriptors for Reading and Writing

    The redirection operator

	 [n]<>word

	 causes the file whose name is the expansion of word to be
	 opened for both reading and writing on file descriptor n, or on
	 file descriptor 0 if n is not specified. If the file does not
	 exist, it is created. 

but am a little unclear on its utility. Under what circumstances can one
both read AND write to the same descriptor? Can anyone provide an
example of where this might be used in practice?

--

-- 
"Oh, look: rocks!"
	-- Doctor Who, "Destiny of the Daleks"
Cameron Simpson | 20 May 2009 00:24
Picon
Picon
Gravatar

Re: The <> redirector

On 19May2009 12:42, Todd A. Jacobs <nospam@...> wrote:
| I found this in the bash manual:
| 
|     3.6.10 Opening File Descriptors for Reading and Writing
| 
|     The redirection operator
| 
| 	 [n]<>word
| 
| 	 causes the file whose name is the expansion of word to be
| 	 opened for both reading and writing on file descriptor n, or on
| 	 file descriptor 0 if n is not specified. If the file does not
| 	 exist, it is created. 
| 
| but am a little unclear on its utility. Under what circumstances can one
| both read AND write to the same descriptor? Can anyone provide an
| example of where this might be used in practice?

I've wanted that a number of times over the years. A UNIX domain socket
open is one example that springs to mind. I think I also wanted to do
this with a named pipe once. I think I've also wanted it for other
stuff.

Anything where you want a single open, especially devices, such as tape
drives.
--

-- 
Cameron Simpson <cs@...> DoD#743
http://www.cskk.ezoshosting.com/cs/

I am a kind of burr; I shall stick.
(Continue reading)

Todd A. Jacobs | 20 May 2009 01:25
Favicon

Re: The <> redirector

On Wed, May 20, 2009 at 08:24:36AM +1000, Cameron Simpson wrote:

> Anything where you want a single open, especially devices, such as tape
> drives.

Yes, well, but if this actually worked the way it sounds, you wouldn't
need to open two named pipes in bash to simulate a co-process. Plus, I
still don't see how you can read and write to the same file descriptor:

    mkfifo bar
    $ echo foo <> bar
    foo
    $ cat bar

Note that bar is being opened for both reading and writing, but contains
nothing. So, what's an actual example of this redirector working in the
real world?

--

-- 
"Oh, look: rocks!"
	-- Doctor Who, "Destiny of the Daleks"
Cameron Simpson | 20 May 2009 02:42
Picon
Picon
Gravatar

Re: The <> redirector

On 19May2009 16:25, Todd A. Jacobs <nospam@...> wrote:
| On Wed, May 20, 2009 at 08:24:36AM +1000, Cameron Simpson wrote:
| > Anything where you want a single open, especially devices, such as tape
| > drives.
| 
| Yes, well, but if this actually worked the way it sounds, you wouldn't
| need to open two named pipes in bash to simulate a co-process. Plus, I
| still don't see how you can read and write to the same file descriptor:
| 
|     mkfifo bar
|     $ echo foo <> bar
|     foo
|     $ cat bar
| 
| Note that bar is being opened for both reading and writing, but contains
| nothing. So, what's an actual example of this redirector working in the
| real world?

Like this (untested):

  mkfifo bar
  exec 3<>bar
  echo foo >&3
  cat bar

Note that "cat bah" prints "foo" but does not return; you can write
further data to the pipe via &3 and the cat will see it.

You can also:

(Continue reading)


Gmane