dimanche 17 novembre 2019

bash headhach

[dechicom@x220f28 list]$ a="\"er gh ";b="$a";c="$b";echo "$a" "$b" "$c"

"er gh  "er gh  "er gh

# name=xx (for information)

[dechicom@x220f28 list]$ eval $name="'"$a"'"

# very hapyy it works !

[dechicom@x220f28 list]$ eval echo $$name 
"er gh

[dechicom@x220f28 list]$ a="\"er \' \` gh ";b="$a";c="$b";echo "$a" "$b" "$c"

"er \' ` gh  "er \' ` gh  "er \' ` gh 

# does it?

[dechicom@x220f28 list]$ eval $name="'"$a"'"
bash: unexpected EOF while looking for matching ``'
bash: syntax error: unexpected end of file

# I am  pissed of !!!

[dechicom@x220f28 list]$ eval name="'""$a""'"
bash: unexpected EOF while looking for matching ``'
bash: syntax error: unexpected end of file

# still have time before going to bed with little caprice: trying not escaping the '

[dechicom@x220f28 list]$ a="\"er ' \` gh ";b="$a";c="$b";echo "$a" "$b" "$c"
"er ' ` gh  "er ' ` gh  "er ' ` gh 

[dechicom@x220f28 list]$ eval $name='$a'

[dechicom@x220f28 list]$ eval echo \$$name 
"er ' ` gh

# So what do I have to escape? Everythig but '?
# Perhaps nothing but the ". Will see tomorrow with blue angel: nasty nasty nasty, control control control!

#after one day, still in wonderland!

[dechicom@x220f28 list]$ c='"';a='\';b="'";echo $c $a $b;[[ $c=$a || $c=$b ]] && echo true
" \ '


# This time I will need veronica Rodriguez.

[dechicom@x220f28 list]$ if [[ "a"="b" ]]; then  echo true; fi
[dechicom@x220f28 list]$ if [[ "a" = "b" ]]; then  echo true; fi

[dechicom@x220f28 list]$ 

# Thank you dear.I'll call you again.But...

[dechicom@x220f28 ~]$ a='\''

> ^C
# How is it possible not to allow escaping the '? This time, I am not sure Veronica will help. I am nearly dead.

#I would have bet it is possible to do:
a='"ggg $a \\    ` \'mm'
# So I don't see any way to protect any string with printable char's against substitution. 

# I will need somebody very patient now. Perhaps Maria Rya. Will see...

#another attempt escaping everithing and unsing "" instead:

function pre_protect (){
    typeset  size
    typeset -i i
    typeset c
    typeset out
    for (( i=0; i<$size; i+=1 ))
eval c="\${1:$i:1}"
    eval $name2="\""$out"\""
    set +o xtrace


[dechicom@x220f28 list]$ . ./csv.sh; a="\$a't'y "; pre_protect "$a" b; echo "--->$a<---" "---->$b<----"; eval echo "$b"; echo $a;
--->$a't'y <--- ---->$\a\'\t\'\y\ <----

# No  I need Brea Brenet

I suppose that, when trying to resolve such problems, programmers decide to switch to python or perl.

But why bash wouldn't  allow us to do more things? Is it possible to create a new eval command that would allow to do such thing without to have to protect the data  that are copied from. Using a special variable name prefix  instead of '$' ? Perhaps a new eval isn't the solution, and we just need indirection (!) that works with array elements? But we have still a problem on the left side ot = (in eval t[3]=$aa).

And I liked also to transfer data between variable without making a copy: aa --> bb.
trans aa bb  # with the option of "unsetting" the origin and working with array. If we don't use array we can use typeset -n name=variablename. I use it to avoid copying data with function arguments.

I think it's possible but I don't have enough knowledge and time to experiment a "fork" of bash.

The reason I say so, is the cost of fork when  calling  programs from within bash and the cost of pipes. Making hour own tools (sort tr .....). Another solution would be to load c library in bash . So we could choose which solution is the best for performances or functionalities.

I  have another idee: offer the possibility for a langage c pgm to be loaded and used as shareable function library in bash. We could simply compile the pgm with a special option or create a format like ELF that would allow it. So we wouldn' have the unix system limitation: one program<->one process. With the AS400 we could have a stack of pgms within the same process, but they were also limitations like the same pgm could no being present  multiple time in the same stack .

I don't know if it is possible, but it would be very wellcome!

function pre_protect (){

    typeset -n __in="$1"
    typeset  size=${#__in}
    typeset -i i
    typeset c
    typeset __out
    for (( i=0; i<$size; i+=1 ))
echo "__out --$__out--"
    set +o xtrace

[dechicom@x220f28 list]$ . ./csv.sh; a="'''\$\"tt\"!"; b=$a; pre_protect "a"; echo "--->$a<---" "---->$b<----"; eval echo "a--$a--"; echo "b--$b--";
__out --\'--
__out --\'\'--
__out --\'\'\'--
__out --\'\'\'\$--
__out --\'\'\'\$\"--
__out --\'\'\'\$\"\t--
__out --\'\'\'\$\"\t\t--
__out --\'\'\'\$\"\t\t\"--
__out --\'\'\'\$\"\t\t\"\!--
--->\'\'\'\$\"\t\t\"\!<--- ---->'''$"tt"!<----

#better, but  need more testing

I want to explain why I need this tool . I am not a good programmer with bash, perhaps I haven't spend enough time reading documentation. But I suppose a lot of peopple got these trouble too. A howto about eval and some tool writen in bash would be welcome. For exemple how to avoid using eval (for newbee) and if it is unavoidable how to use it.

Let see another problem that require eval (on the left side of "=" )

[dechicom@x220f28 list]$ a=t   
[dechicom@x220f28 list]$ i=3
[dechicom@x220f28 list]$ !a[!i]=5
bash: !a[!i]=5: event not found

# it would be very nice to allow this. Is there a bash-core-design that make it unpossible or very hard to allow? 

[dechicom@x220f28 list]$ $a[!i]=5
bash: t[!i]=5: command not found

[dechicom@x220f28 list]$ eval $a[!i]=5
# no error message but it hasn't worked

[dechicom@x220f28 list]$ echo ${t[3]}

[dechicom@x220f28 list]$ a=t; i=7;eval $a[$i]=55;echo ${t[7]};
# this time it worked and it is not very risky  because array name don't allow any characters and index are numbers.

#after spending a lot of time with Franziska Facella (They say she is out of business), it seems to be that there is no need to pre_protect a variable before using eval. This is the fault of people saying constantly over internet, that we have to quote variables for our own good ("$var"). There is no need to quote when your are assigning an only variable  to an array or another variable. Whatever ever; after getting more experienced I still have difficulties using eval. Some methods must be learned for good to avoid confusion and bugs. I will publish some code that gives exemples. I needed much time to do it.  So I hope you will be leniant.

# The solution to avoid "protecting" a variable for eval use is :use only one variable argument and if needed, build this variable in several steps):

[dechicom@x220f28 list]$ a="\$a't'y ";b=$a; eval_string="echo \$a" ; eval $eval_string ; echo $b;
# I haven't seen this solution proposed in any document about bash. As I allready said I haven't read enough. I think this simple solution should be written in the reference documentation. Is It ?

#perhaps pre_protec can be useful in some other case,

# Special thanks to Casey Chase one of my beloved actress.

# In this experimentation, the result is so astonishing that I might get the nobel Prize!

# this is the tda.sh script!
printf "a<<%s>>\n" $1
printf "b<<%s>>\n" $2

exit 0 # very optimistic!

[dechicom@x220f28 test]$ a=$(echo -e"\$a'\nt'y \\\t\t x");b=$a;echo -e $a;echo -e $b; echo "------"; eval_string="./tda.sh \"\$a\" \"\$b\" " ; eval $eval_string 
t'y \t x
t'y \t x

# Am I  seeing an pink Elephant? It is Anjelica (Kristal boyd) fault. She should have said me that the printf (the bash builtin) consume all the arguments. This is not a bug!
# So I am still searching a way to pass arguments to a pgm in a safe way.
# For the moment no problems with variable assignation (it seems) and function arguments (using typeset -n) after passing an argument with the variable name  as a pointer. 

# I hope I have found the solution now. Anjelica should be punished! I will talk to rocco about this!

# this is the tda.sh script!
printf "a<<%s>>\n" "$1"
printf "b<<%s>>\n" "$2"

exit 0 # very optimistic!

[dechicom@x220f28 list]$ a=$(echo -e "\$a'\n\"t'y कु \\\t\t x");b=$a;echo "a<<$a>>";echo  "b<<$b>>"; echo "------"; ./tda.sh "$a" "$b" ; echo "========";eval_str="./tda.sh \"\$a\" \"\$b\""; eval "$eval_str";
"t'y कु \t x>>
"t'y कु \t x>>
"t'y कु \t x>>
"t'y कु \t x>>
"t'y कु \t x>>

"t'y कु \t x>>

# Rocco says "she has already been enough punished by me!" 

# It might be dangerous to go through the mirror so often!
# perhaps I need treatment?

So, if I dont' want to ge t fucked by bash, I might work in  two ways:
-- getting an "intimate" understanding of the bash interpreter by experimenting and reading documentation. It might take a lot of time .... 
-- try to get or build some simple,basic rules that allow to work safely with datas using variable, quotes and eval. 

I suppose, some people like me, have used bash a lot of time without knowing what it would cost them to use its full potential.

I have been working with the GNU core utilities for a long time, I think tools like grep or sed are very powerful. I am not an expert at all using them. I sometime spend a long time without using them. So I forget the syntax. Not able to understand code I didn't write or even my own code.  For example there is again a problem knowing whether a character is a control character and if it needs to be escaped. I will perhaps try to use Yacc to translate these complex grep expressions in something more understandable. Perhaps somebody has already done it . I think grep expression should be allowed to be written in both manners and that they should even allow us to translate a form in an other. 
About the GNU project: I don't think that opening source is enough, we must also find ways -when it is possible- to ease working with the tools. Some people might find that proposing powerful tools -but very hard to use tools- is a sign that those people don't really want to share their knowledge. Or they simply don't know. It might be wrong of course: it might simply be that, if they are not able to use these tools they should better find another occupation.

Another word about reference documentations: It is also very hard for me to use them in order to start learning how to use the tools. I would deter people to use them  as a first step if they can find a good HOWTO or a good book. These pedagogic documents should be proposed everywhere in the GNU documentation. And people having the talent to produce these documents should be helped and praised by the GNU project. This talent being: the ability to make us learn the most important concepts in the easiest way  possible.  The Talent also to give us a glimps of the power of the tools and the envy to know more. I find it difficult to learn using code if I can't test an example of it. I am never completely sure I have understood what I have read. So it is better if I don't memorize immediately what I read.  

Aucun commentaire:

Enregistrer un commentaire