[Tutor] Pass arguments from bash script to embedded python script

[Stephen P. Molnar]

Thank you for your reply.

Here is my code as formatted, with extraneous print statements removed:

> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> """
> Created on Fri Oct 11 09:36:30 2019
>
> """
>
> import os
> import glob
> import numpy as np
>
> fileList = []
> filesList = []
>
> for files in glob.glob("*.log"):
>     fileName, fileExtension = os.path.splitext(files)
>     fileList.append(fileName)
>     filesList.append(files)
>
>
> fname = fileList
> for fname in fileList:
>     fname
>
> fname1 = fname+'.log'
> fname2 = fname+'-dG'
>
>
> def dG(filesList):
>     data = np.genfromtxt(fname1, usecols=(1), skip_header=27, 
> skip_footer=1, encoding=None)
>     np.savetxt(fname2, data, fmt='%.10g', header=fname)
>     return(data)
>
> data = dG(filesList)
>

Please see my additional comments interspaced below:



On 10/23/2019 05:52 PM, David L Neil via Tutor wrote:
> On 24/10/19 8:08 AM, Stephen P. Molnar wrote:
>
>
> > I have revised my script to make use of the def function:
>
> Back in FORTRAN we used to write:
>
>     FUNCTION FUNCNAME( args )
>     - specific code to implement some purpose
>
Lost in the mist of time (the early 1960's) I was barely proficient in 
FORTRAN II.
> This, in Python, is similar. Try 'translating' "def" as "define 
> function", to clarify: 'I am defining function dG'...
>
>
> Please copy-paste the exact code in-use and errmsg-received, because 
> what came-through doesn't make sense - likely re-formatted by the 
> email system.
>
>
> This is a problem:
>
> > fname = fileList
> > for fname in fname:
> >      fname
>
> - fname is first set to a list
> - then it is used as an iterator (right side)
>     AND as a (single) variable
> - finally it is used for something?what?
>
> Apparently the same varNM is being used and re-used, for quite 
> different purposes!
>
> Whereas fileList gives a clear impression that it is a collection of 
> items, "fname" suggests that it holds a single file's name.
>
> That said, why not?
>
>     for fname in fileList:
>         # do something with fname
>
> NB what followed the above (in the email listing) should likely be 
> indented (per criticism, above)
>
Yes
>
> Also:
>
> > where fileList = ['C-VX3', '15-7', '14-7']
>
> This is 'for our information' and not actually part of the 
> code-snippet - is it?
>
Correct
>
> Is the dG function designed to accept a single file-name at a time, eg 
> 'C-VX3' or all three at once?
>
One at a time
> > data = dG(filesList)
>
> is declaring all three/the entire list as parameters!
>
>
> The current design (it seems to me, reading-around any email 
> re-formatting issue)
> 1 (loop nr1) scan the currentDIR for .log files
> 2 add each .log file to a list [you advise that there are three]
> 3 (loop nr2) pick each fileNM in the (above) list, and
> 4 dG() it
>
> If you combine the two loops, many (apparent) problems should 
> 'disappear':
>
> 1 scan the currentDIR for .log files (existing)
> 2 manipulate the fileNM (existing)
> 3 dG() it (existing)
>
>
> Which brings me back to "naming":
>
> > for files in glob.glob("*.log"):
>
> <<<
>  glob.glob(pathname, *, recursive=False)
>
>     Return a possibly-empty list of path names that match pathname...
> >>>
>
> - is "files" a (single) file's *name* or a list of file-names?
> (the glob.glob part is indeed a list, but files is (a) singular and 
> (b) a file-name (actually, a "path-name").)
>
> Apologies, if seeming pedantic, but an incorrect choice of varNM may 
> introduce a confusion which prevents comprehension/debugging.
>
Well, I'm certainly  confused!! (I can be pedantic along with the best.)
>
> Good idea to use some 'debug prints'! Even better, that if you are 
> using r3.8 you can take advantage of a brand-new feature:
>
> > print('fname = ', fname)
>
> print( f"fname =" )
>
> NB the "f" preceding the quoted-string is deliberate and important - 
> we call these "f-strings".
>
> My ToDo list includes (continuing to research/check first, then) 
> upgrading to r3.8 - even as 'f-string debug printing' is the nr1 
> personal appeal to this lazy-boy!
>
I have enough problems iwth 3.7.
>
> To help with learning Python, are you aware that Python allows, even 
> enables, you to experiment and thus develop a program, line-by-line?
>
> - open a terminal window and start python3
> - try these two lines (abstracted from the code):
>
> import glob
> glob.glob("*.log")
>
So far, so good:

> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> """
> Created on Thu Oct 24 08:48:59 2019
>
> """
>
> import glob
>
> ligands =[]
> ligands = glob.glob("*.log")


> NB the second statement is an implicit version of:
>
>     print( glob.glob("*.log") )
>
> - you should see something like (your):
>
>     ['C-VX3', '15-7', '14-7'] 

That's what was returned.

> Now, you have an exact illustration and on-screen evidence of what is 
> happening!
>
> You can continue adding (your) lines of code, one-at-a-time. (in which 
> case, at least initially, avoid loops and aim to get (only) 'the first 
> one' to work). Once you have learned the necessary Python syntax and 
> bent the code to your will, the pertinent/working parts can be copied 
> into a editor and saved as a file. Then you can install loops (and 
> indents!) and all the bells-and-whistles your little heart desires...
>
> Sage advice passed to a (much) younger me: "Make it work, before you 
> make it better". Python's "REPR" makes enacting such advice SO much 
> easier!
>
>
> Also, which editor are you using?
>
Spyder-3.6.6
>
> WebRef: https://docs.python.org/3.7/library/glob.html

-- 
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1