Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Multiple processing of a text file

10 views
Skip to first unread message

Ken Rock

unread,
Jun 16, 2017, 2:18:28 AM6/16/17
to
Hi,
I hope I'm on the correct user group.
I need to input a text file into a program and store the treated text file. Using mac Terminal, I can get it to work cmd/program <text001.txt >nutext001.txt. I have to do this many times i.e. text001.txt to text100.txt.
This will be very tedious in Terminal by direct input. Please can anyone suggest a quicker way to do it?

Michael F. Stemper

unread,
Jun 16, 2017, 10:17:35 AM6/16/17
to
On 2017-06-16 01:18, Ken Rock wrote:

> I hope I'm on the correct user group.

Assuming that you want an answer that will work under bash, you're in
the right news group.

> I need to input a text file into a program and store the treated text file. Using mac Terminal, I can get it to work cmd/program <text001.txt >nutext001.txt. I have to do this many times i.e. text001.txt to text100.txt.
> This will be very tedious in Terminal by direct input. Please can anyone suggest a quicker way to do it?

How about something along the lines of:

for file in text???.txt
do
cmd/program < $file > nu$file
done

If the names of the files that you need to proess don't actually
match "text???.txt", or if you have other files that match it,
you could change the regular expression, or you could move just
the relevant files to a subdirectory created just for this task.

However, if you use a different directory, you'll need to change
"cmd/program" to correctly match the relative path to program.

Another option in place of "for file in text???.txt" that you might
use if you only want to deal with the first 100 files:

n=1001
while [[ $n -le 1100 ]]
do
fn=text`echo $n | sed 's/^1//'`.txt
cmd/program < $fn > nu$fn
((n+=1))
done

What I've done here is come up with a way to count from 001 through
100, with the output always having three digits, demonstrated here:

username@hostname$ n=1001
username@hostname$ echo $n | sed 's/^1//'
001
username@hostname$ ((n+=1))
username@hostname$ echo $n | sed 's/^1//'
002
username@hostname$

The variable "fn" then gets this counter, preceded by the string "text"
and followed by the string ".txt".

The sed command just strips off the leading "1" on the fly. Why do this?
Because if you just initialize to "001" and then increment, this'll
happen:

username@hostname$ n=001
username@hostname$ echo $n
001
username@hostname$ ((n+=1))
username@hostname$ echo $n
2
username@hostname$


P.S. Make sure to create a scratch directory and copy all of the
contents of your base directory there, in case of errors.

--
Michael F. Stemper
Nostalgia just ain't what it used to be.

Ken Rock

unread,
Jun 16, 2017, 11:19:33 AM6/16/17
to
Thank you for your prompt reply, Michael. You have given me a lot to think about! I will try out your suggestions but I have a steep learning curve to climb. Again, many thanks

Ken Rock

Michael F. Stemper

unread,
Jun 17, 2017, 7:11:17 PM6/17/17
to
I threw a lot of stuff at you. If, after trying it, some of it
still is confusing, feel free to ask more questions. This news group
seems to be pretty low-volume.

Also, I'd like to point out something about the subject line of your
original post. The subject is "Multiple processing of a text file."
However, what you described was "Processing of multiple text files",
which is a subtle, but important, difference. Getting a proper
description of the problem in your own mind is usually the first step
towards finding a solution.

(That's obviously not just true when you're trying to do something in
bash, but in general.)

Good luck!

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.

Joe Rosevear

unread,
Nov 26, 2017, 3:16:11 AM11/26/17
to
Michael F. Stemper <michael...@gmail.com> wrote:

...

> I threw a lot of stuff at you. If, after trying it, some of it
> still is confusing, feel free to ask more questions. This news group
> seems to be pretty low-volume.

It is low volume, but it seems to be a working group on a topic that is
under-valued. That is a good thing.

-Joe

Michael F. Stemper

unread,
Aug 20, 2018, 7:02:25 PM8/20/18
to
Agreed.

I appear to have expressed myself poorly. I meant that "since the group
is low volume, posting more questions is not going to be a problem."

--
Michael F. Stemper
2 Chronicles 19:7
0 new messages