the "here-doc" approach is what i used. i never heard it called that (i called it "embedded input"). i never participated in a bash forum ... all they had at the time were mailing lists and i don't like mailing lists ... so that may explain never seeing that terminology. i am glad there is a forum around for Python. anyway, it worked just fine.
i had previously organized this (originally a "one off") script with a bunch of functions so i could keep lines relatively short (max 184, my text screen width) and separate pipelines. the functions had "awk" commands that were not working. i rewrote them 3 times and gave up and switched to Python. the first coding in Python worked. now i am thinking of reducin these 3 functions to just 1 to simplify the pipelines that call them.
in theory, i could have done it all in Python. but i already had a bash script to gather the data (a bunch of ssh and rsync calls) and at first i thought this would be a quickie mod. it wasn't.
as for which way to embed is best, i'd say just do the whole thing in Python. but in some cases, especially with pre-existing code, it can be better to make parts in another language. in the case of a part being in Python, it could be a separate Python script. but for many things, i like to keep things all in on file if it can remain readable. for Python in bash, i was hoping it would be simple enough to remain readable. i was certain it could be made to work. just how simple was my big question. fortunately the "here-doc" approach was quite simple.
if a command line option like "+4" could be added to mean: read the code from the specified file descriptor, this would have been even simpler.
i had previously organized this (originally a "one off") script with a bunch of functions so i could keep lines relatively short (max 184, my text screen width) and separate pipelines. the functions had "awk" commands that were not working. i rewrote them 3 times and gave up and switched to Python. the first coding in Python worked. now i am thinking of reducin these 3 functions to just 1 to simplify the pipelines that call them.
in theory, i could have done it all in Python. but i already had a bash script to gather the data (a bunch of ssh and rsync calls) and at first i thought this would be a quickie mod. it wasn't.
as for which way to embed is best, i'd say just do the whole thing in Python. but in some cases, especially with pre-existing code, it can be better to make parts in another language. in the case of a part being in Python, it could be a separate Python script. but for many things, i like to keep things all in on file if it can remain readable. for Python in bash, i was hoping it would be simple enough to remain readable. i was certain it could be made to work. just how simple was my big question. fortunately the "here-doc" approach was quite simple.
#!/bin/bash doit() { python3 /proc/self/fd/4 4<<EOF print('this is python') EOF } echo foo doit doit echo bar exit 0i didn't need to use the -c option, which i thought would make things less readable.
if a command line option like "+4" could be added to mean: read the code from the specified file descriptor, this would have been even simpler.
Tradition is peer pressure from dead people
What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.