[ale] scripts, file I/O, and loss of hair

[Jim Kinney]

On Thu, May 12, 2011 at 11:51 PM, The Don Lachlan <ale-at-ale.org@
unpopularminds.org> wrote:

> On Thu, May 12, 2011 at 08:48:59PM -0400, Jim Kinney wrote:
> > On Thu, May 12, 2011 at 6:45 PM, The Don Lachlan <ale-at-ale.org@
> > unpopularminds.org> wrote:
> >
> > > On Thu, May 12, 2011 at 05:57:42PM -0400, Jim Kinney wrote:
> > > > that expects a {binary name} < {input data file}. {input data file}
> is
> > > > variably named and often 20+MB. Changing {binary name} to work better
> is
> > > > political (think Fortran 77 base code - someone in charge got their
> PhD
> > > with
> > > > that program).
> > > > so things must work as they are with my little tweaks around the
> edges.
> > > > until I blow away the decades old mess and start over in C.
> > >
> > > That doesn't make any sense.
> > >
> > > If the Fortran code expects the data as a stream (that's what the
> redirect
> > > does), then why are you trying to get the file name in a shell script?
> What
> > > is your objective with this?
> > >
> >
> > For logging the combination of which fortran binary with which input file
> > I'm simulating parts of a process with a shell script. The fortran code
> runs
> > for many hours.
>
> Ok, so you want to modify the Fortran code to log the input file. Right?
>

Absolutely not. No fortran modifications are in order.

The fortran code is sometimes called directly and sometimes called with a
shell script wrapper. This little bit I was hacking on needed to be able to
handle either form. In short, I've added a wrapper to a wrapper.

>
> If so, you could specify the input file twice and then have Fortan pull the
> first line of input as the name of the input file.
>
> $ script file.data < file.data
>
> but anything after that redirect is handled separately by the shell and not
> easily reachable by the Fortran code.
>
>
> Regarding cat and file redirection, you're confusing things.
>
> > I have a simple test script my_script
> >
> > #!/bin/bash
> > # this is a crap script
> > myout="$2"'.crap'
> > directions=$(cat $2)
> > echo "$myout"
> > echo "$directions"
> > exit
> >
> > It is launched by:
> > ./my_script < test1.dat
>
> That's what you originally wrote. I said use
>
>  directions=`<${1}`
>
> Which will work if you do "script file.data < file.data".
>

But what _I_ wanted was the value of $2 followed by .crap. Yes. The useless
cat to populate directions is best written as a redirect.

>
> But you sent a whole bunch of errors here because you were trying to do
> something different, mostly stuff I don't understand.
>

I sent my testing where I was clearing the cobwebs by creating a test bed.

>
> > FYI:
> >      shell variable redirect
> >
> > fred='foo bar'
> > mary=`<${fred}`
> > -bash: ${fred}: ambiguous redirect
> >
> > mary=`cat ${fred}`
> > cat: foo: No such file or directory
> > cat: bar: No such file or directory
>
> Where did that come from? You cat files. If foo and bar don't exist, you
> can't cat them. If you're trying to pull from multiple files, then the
> redirection won't work any more than "myscript < foo bar" would work.
>

Again. I was testing scenarios to get the logic in my mind. I don't
"program" but about once or twice a year.

>
> >     get contents of variable
> > mary=`echo ${fred}`
> > echo $mary
> > foo bar
> >
> >     make a file
> > echo "foo bar" >> fred
> > mary=$(<$fred)
> > -bash: $fred: ambiguous redirect
>
> Isn't $fred still holding "foo bar"? You were looking for "fred".
>

yes. $fred is still a container for a string and not a string that is an
actual file name. I was trying to push the contents of fred into mary when I
finally remembered that redirects have to be associated with files and that
I had scrambled the two connotations in my mind.

>
> >    read file
> > cat fred
> > foo bar
> >
> >     redirect file contents to shell variable
> >  mary=`<$fred`
> > -bash: $fred: ambiguous redirect
>
> See above.
>
> >    create a reference (as shell var) to file to have redirect "go
> through"
> > john='fred'
> > mary=`<${john}`
> > echo $mary
> > foo bar
> >
> >
> >     or just 'cat' the damn thing and irritate R. Schwartz again :-)
> > suzy=$(cat ${john})
> > echo $suzy
> > foo bar
>
> WTF, dude? You have two equivalent code blocks:
>
>  john='fred'
>  mary=`<${john}`
>  echo $mary
>  foo bar
>
> versus
>
>  john='fred'
>   suzy=$(cat ${john})
>  echo $suzy
>  foo bar
>
> That is *exactly* what you're doing in your test script.  The first is
> safer
> and requires no extra work.
>

Yes they are the same. Again testing to see if there are any discernible
differences. I do know that `` notation is only useful for a single
functional call while $() can be nested. The later is the preferred method
as the former is not as capable.

Many thanks for the pointers and reminders. Once the fog began lifting, I
was able to do the last bit of bug bashing <snigger> and finish the testing
of the wrapper. The real test begins shortly as the fortran warms up.

>
> -L
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
-- 
James P. Kinney III

As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as they
please, and those who survive will be left to contemplate the outcome.
- *2011 Noam Chomsky*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110513/98e35805/attachment.html