Jump to content











Photo
- - - - -

My grub4dos Utilities

grub4dos scripting

  • Please log in to reply
47 replies to this topic

#26 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 28 October 2022 - 08:33 PM

I fully forgot to mention that call Fn.11 is unable to process \x00, not even if in "%VARIABLE%" only :huh:

 

I made some fresh print-screens to illustrate. Most important consequence is: if VARIABLE contains \x00 the return value of call Fn.11 is ALWAYS 'false'.

 

So more or less safe should be: call Fn.11 "%VARIABLE%" "\x00" && some command... However: command will never be executed in this case.

Not safe will be: call Fn.11 "%VARIABLE%" "\x00" || some command... Command will always be executed if VARIABLE contains \x00.

 

call Fn.11 behavior with x00 I.jpg

 

BTW: use of double-quotes around %VARIABLE% and \x00 is not helpful, like earlier mentioned about other cases.

 

 

In case of TEXTSTAT.G4B counting of 'phrase' [one char]\x00 or \x00[chars] will give an error because of following two code-lines in the script (version 0.7, not yet ready):

 

echo -e "%count%" | set countlen=
set /a countlen=%@retval%-2 &; if not exist count && set /a countlen=0 ! if not %countlen%>=1 && endlocal && set "message=%COUNT%" && set result= && goto :eof

 

BTW compare with lines 175-176 of version 0.6.1
 

 

Textual \x00 gives no problem:

 

TEXTSTAT.g4B behavior with bsx00 and textual bsbsx00 (two bachslashes) I.jpg

 

 

 

 

 



#27 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 28 October 2022 - 09:44 PM

Fn.11 searches until it gets to the end of the string which is a 0 byte
I.e. a byte of zero is eos byte
So \x00 is going to shorten the string
That is why I suggested replacing \x with some other characters before you start using Fn.11.

#28 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 29 October 2022 - 01:23 AM

I understand your approach, but I can't give up so fast to try without using memory. :(

 

I am using call Fn.11 quite a lot. I did a quick count of use in my utils with help of TEXTSTAT.G4B:

 

call Fn.11 in My grub4dos Utilities I.jpg

 

Today I found out shortening with \x00 using echo -e - for instance I can use now echo -e -n $[0x00]"$[0xF0]some text containing grub4dos code-lines\x00" && if "%somevar%">="somevalue" && echo more text without second $[0x00]" which will 'cost' one black space after.

 

Also interesting seems to be echo -e "%variable%\x00" > (md)..... last double-quote is not redirected to memory.

 

However in a Fn.11-call there does not seem to be any 'shortening', the call simply gives 'false' if first argument is containing \x00 - even with 'normal' chars before.

 

But may be my experiment was not clear. Try for instance:

 

call Fn.11 "abc\x00" "a" && echo TRUE ! echo FALSE

 

With 'shortening' IMHO there would be no unsafe option -_-

 

Luckily grub4dos commands will not give variables containing \x00 as far I can imagine, so IMHO only user input or scripting has to be managed.



#29 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 29 October 2022 - 08:07 AM

any \x00 will just shorten the whole line and so it wont make sense to the Fn.11 parser

 

see screenshot

 

 

Attached Thumbnails

  • echoo.JPG


#30 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 29 October 2022 - 10:37 PM

Thanks, make it more understandable to me.

 

While working on a script to filter string before 'feeding' to Fn.11 I found a case where \x00 gave TRUE (see output of --echo=mem=0x3A9000 lines 0x3A9060-0x3A907A):

 

call Fn.11 TRUE for dbq many x20x22 including x00dbq dbqx21dbq + echo --mem=0x3A9000=256 + read %@retval%.png

 

But it seems in fact parts of the string before \x00 are used only, because of this stupid way \x22 is treated by the Fn.11 call. Only first \x20 seems to be found by another \x20 in the same string. :angry:

 

So my current approach is doomed to fail. :(



#31 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 01 November 2022 - 10:26 PM

I am working on call Fn.11 more following @steve6375´s approach he gave in Topic #23.

 

I choose to have STRING as second argument on command-line to 'get' highly spaced strings mixed with double-quotes too (after shifting first argument away).

 

With set ARG=%* (no double-quotes!) this is working, but what bothers me there is always a space behind. Why?

I helped myself with set "ARG=ARG:~0,-1" on next code-line, but don't know if it's fully safe... :unsure:

 

Difference with %1....%9 is on print-screen:

 

Fn11.G4B Why STRING with %asterisk always space behind I.jpg

 

BTW I never used set ARG=%* before, just seems 'handy'

 

My solution seems bad for command-line use: spaces 'left behind' by the cursor are included too (but with %9 one less):

 

Fn11.G4B Why STRING with %asterisk always space behind - or more if cursor is shifted II.jpg

 

BTW command-line use is not my intention. :ph34r:



#32 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 November 2022 - 09:12 AM

Side note (semi-random) what happens using SHIFT?

 

:duff:

Wonko



#33 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 02 November 2022 - 09:43 AM

I dont understand the problem?

 

From https://rmprepusb.co...-grub4dos/021b/

 

About batch scripts:

 

Batch script file must begin with! BAT to.

Batch script can exit by exit or exit a call to call, exit can return an exit code, such as exit 1

Batch script or call call can accept parameters:

%0 is the command itself

%* On behalf of all parameters (not including 0%)

%1-%8 represents the first one to the first eight parameters

%9 represents all remaining parameters

You can use the shift discard parameter, the default discard the first argument, you can pre-shift 6 dropped six parameters. The remaining parameters will move forward.



#34 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 02 November 2022 - 04:23 PM

@Wonko: thanks for the suggestion. Tested too, no difference.

 

@steve6375: thanks for the info.

I do not want to criticize anyone, but I found there is still ONE space difference at the end between using %*  and %9.

 

I made a quick script for testing from command-line and in a call.

All tests in Virtual Box - Version 6.1.38 r153438 (Qt5.6.2)

 

TEXTSTAT.G4B found no spaces at end of any line:

 

TEXTSTAT.G4B ARG.g4b.jpg

 

My ultimate target is to read-out all possible STRING's from a call, to use it for my intermediate project Fn11.g4b to test a string for \x00, \x22 AND for the presence of double-quote char.

 

I imagined a problematic variable for read-out with %1-%8 or %* (and variations with '~').

 

On first print-screen the variable 'ARG' is set and used - WITHOUT surrounding double-quotes - on the command-line of ARG.g4b I made

 

ARG.g4b I.jpg

 

BTW: cursor was immediate behind last '%'

 

As can be seen there is a space behind with %* and not with %9 :unsure:

Also shift was shifting as expected, but no difference regarding 'the extra space'.

And there was a surprise for me too: all spaces between %1-%8 are reduced to one space.  :wacko:

 

 

On next print-screen the script continued with the first call of %* (without double-quotes around):

 

ARG.g4b II.jpg

 

New surprise: one extra space added to %* and %9, %* has now TWO trailing spaces. :blink:

 

 

Using double-quotes around in call :conv "%*" made no difference regarding reducing %1-%8. The extra space is still there, but each surrounding the last of the two added double-quotes. See next print-screen:

 

ARG.g4b III.jpg

 

BTW of course %9 is not available, 'space' after '=' is just some artifact using $[0xF0]%9 with empty %9. :(

(On last line the echo-artifact. I believe there is a new grub4dos 0.4.6a version, I will test).

 

And so on. However no reduction of %1-%8 if using "%ARG%" in the call:

 

ARG.g4b V.jpg

 

--------------------------------------

 

Just for the record: last print-screen shows echo $[0xF0] with various cursor positions - so spaces. On first and last line NO spaces. On second line ONE space:

 

echo echos space with highlight colorcode without anaything after identical with one space on command-line II.jpg

 

--------------------------------

 

Edit: tested with new version of grub4dos (20221026)

[The .calc function supports 64-bit division. Added variable @retval64 to return the 64-bit computed value of the calc function. issues #380

. The [-P:XXYY] function of the echo function allows XX(YY) to be a hexadecimal value. issues #383
. Fixed the $[ABCD] function of the echo function. In the VM (VBOX) console under the BIOS environment, if the first character is used, the screen will be blurred when scrolling. issues #381
]*

   *Translation by Google Translate

 

Although issue #381 seems to be solved (did one quick test - first print-screen), no difference for trailing space with %*:

 

Blurred echo on VBox solved with grub2dos 20221026 I.jpg ARG.g4b with grub4dos 20221026 I.jpg ARG.g4b with grub4dos 20221026 II.jpg

 

BTW in case of %* no difference between graphics mode/ console mode. :rolleyes:

 

------------------------------------

 

Script inside the zip with password because of warning for virus or malware. Pass: ARG

 

Attached File  ARG.g4b.zip   836bytes   139 downloads

 

BTW on my Windows 10 computer attachment was downloaded as :'ARG.2v3A7Qk-.g4b(2).zip.part' but after renaming to zip I could open it. :)

 

To be sure, if anyone has problems with the zip still the full script:

!BAT
#-#+ ARG.G4B v0.1 (20221102), by deomsh
#-#+ Function: test behavior of '%*', '%~*', '%9', '%~9', '%1, '%~1', %ARG% and "%ARG%" on command-line and in call's
debug 1
echo $[0x00]"$[0x0F]%^*$[] =$[0xF0]%*
echo $[0x00]"$[0x0F]%^~*$[]=$[0xF0]%*
echo $[0x00]"$[0x0F]%^9$[] =$[0xF0]%9
echo $[0x00]"$[0x0F]%^~9$[]=$[0xF0]%~9
echo $[0x00]"$[0x0F]%^1$[] =$[0xF0]%1
echo $[0x00]"$[0x0F]%^~1$[]=$[0xF0]%~1
echo $[0x00]"$[0x00]"$[]shift
shift
echo $[0x00]"$[0x0F]%^*$[] =$[0xF0]%*
echo $[0x00]"$[0x0F]%^~*$[]=$[0xF0]%*
echo $[0x00]"$[0x0F]%^9$[] =$[0xF0]%9
echo $[0x00]"$[0x0F]%^~9$[]=$[0xF0]%~9
echo $[0x00]"$[0x0F]%^1$[] =$[0xF0]%1
echo $[0x00]"$[0x0F]%^~1$[]=$[0xF0]%~1
set "ARG1all=%*"
set "ARG1~all=%~*"
set "ARG1_9=%9"
set "ARG1~9=%~9"
set "ARG1~1=%~1"
set "ARG1_1=%1"
echo $[0x00]"$[0x0F]ARG1all$[] =$[0xF0]%ARG1all%
echo $[0x00]"$[0x0F]ARG1~all$[] =$[0xF0]%ARG1~all%
echo $[0x00]"$[0x0F]ARG1_9$[] =$[0xF0]%ARG1_9%
echo $[0x00]"$[0x0F]ARG1~9$[] =$[0xF0]%ARG1~9%
echo $[0x00]"$[0x0F]ARG1_1$[] =$[0xF0]%ARG1_1%
echo $[0x00]"$[0x0F]ARG1~1$[] =$[0xF0]%ARG1~1%
echo $[0x00]"$[0x0F]call :conv %^*$[0x00]" && pause Key... && clear
call :conv %*
echo $[0x00]"$[0x0F]Returned from :conv using %^* - echo on new line
echo $[0x00]"$[0x0F]call :conv "%^*"$[0x00]" && pause Key... && clear
call :conv "%*"
echo $[0x00]"$[0x0F]Returned from :conv using "%^*" - echo on new line
echo $[0x00]"$[0x0F]call :conv %^9$[0x00]" && pause Key... && clear
call :conv %9
echo $[0x0F]Returned from :conv using %^9 - echo on new line
echo $[0x00]"$[0x0F]call :conv "%^9"$[0x00]" && pause Key... && clear
call :conv "%9"
echo $[0x0F]Returned from :conv using "%^9" - echo on new line
echo $[0x00]"$[0x0F]call :conv %^ARG%$[0x00]" && pause Key... && clear
call :conv %ARG%
echo $[0x00]"$[0x0F]%Returned from :conv using %^ARG% - echo on new line
echo $[0x00]"$[0x0F]call :conv "%^ARG%"$[0x00]" && pause Key... && clear
call :conv "%ARG%"
echo $[0x00]"$[0x0F]Returned from :conv using "%^ARG%" - echo on new line
echo $[0x00]"$[0x0F]call :conv %^*$[0x00]" && pause Key... && clear
call :conv %* && echo $[0x00]"$[0x0F]Returned from :conv using %^* - echo on same line
echo $[0x00]"$[0x0F]call :conv "%^*"$[0x00]" && pause Key... && clear
call :conv "%*" && echo $[0x00]"$[0x0F]Returned from :conv using "%^*" - echo on line
echo $[0x00]"$[0x0F]call :conv %^9$[0x00]" && pause Key... && clear
call :conv %9 && echo $[0x00]"$[0x0F]Returned from :conv using %^9 - echo on same line
echo $[0x00]"$[0x0F]call :conv "%^9"$[0x00]" && pause Key... && clear
call :conv "%9" && echo $[0x00]"$[0x0F]Returned from :conv using "%^9" - echo on same line
echo $[0x00]"$[0x0F]call :conv %^ARG%$[0x00]" && pause Key... && clear
call :conv %ARG% && echo $[0x00]"$[0x0F]Returned from :conv using %^ARG% - echo on same line
echo $[0x00]"$[0x0F]call :conv "%^ARG%"$[0x00]" && pause Key... && clear
call :conv "%ARG%" && echo $[0x00]"$[0x0F]Returned from :conv using "%^ARG%" - echo on same line
pause clear after Key and continue... && clear
echo $[0x00]"$[]shift && shift && shift && shift && shift && shift && shift && shift
shift && shift && shift && shift && shift && shift && shift && shift
echo $[0x00]"$[0x0F]%^*$[] =$[0xF0]%*
echo $[0x00]"$[0x0F]%^~*$[]=$[0xF0]%*
echo $[0x00]"$[0x0F]%^9$[] =$[0xF0]%9
echo $[0x00]"$[0x0F]%^~9$[]=$[0xF0]%~9
echo $[0x00]"$[0x0F]%^1$[] =$[0xF0]%1
echo $[0x00]"$[0x0F]%^~1$[]=$[0xF0]%~1
echo && pause --wait=0 Test without space behind: echo $[0xF0]
echo $[0xF0]
goto :eof

:conv
setlocal
echo $[0x00]"$[0x0F]in %0
echo $[0x00]"$[0x0F]%^*$[] =$[0xF0]%*
echo $[0x00]"$[0x0F]%^~*$[]=$[0xF0]%*
echo $[0x00]"$[0x0F]%^9$[] =$[0xF0]%9
echo $[0x00]"$[0x0F]%^~9$[]=$[0xF0]%~9
echo $[0x00]"$[0x0F]%^1$[] =$[0xF0]%1
echo $[0x00]"$[0x0F]%^~1$[]=$[0xF0]%~1
set ARG1all=%*
set "ARG1xall=%*"
set ARG1_9=%9
set "ARG1_x9=%~9"
set ARG1_1=%1
set "ARG1_x1=%~1"
echo $[0x00]"$[0x0F]ARG1all$[] =$[0xF0]%ARG1all%
echo $[0x00]"$[0x0F]ARG1xall$[]=$[0xF0]%ARG1xall%
echo $[0x00]"$[0x0F]ARG1_9$[]  =$[0xF0]%ARG1_9%
echo $[0x00]"$[0x0F]ARG1_x9$[] =$[0xF0]%ARG1_x9%
echo $[0x00]"$[0x0F]ARG1_1$[]  =$[0xF0]%ARG1_1%
echo $[0x00]"$[0x0F]ARG1_x1$[] =$[0xF0]%ARG1_x1%
echo shift && shift
echo $[0x00]"$[0x0F]%^*$[] =$[0xF0]%*
echo $[0x00]"$[0x0F]%^~*$[]=$[0xF0]%*
echo $[0x00]"$[0x0F]%^9$[] =$[0xF0]%9
echo $[0x00]"$[0x0F]%^~9$[]=$[0xF0]%~9
echo $[0x00]"$[0x0F]%^1$[] =$[0xF0]%1
echo $[0x00]"$[0x0F]%^~1$[]=$[0xF0]%~1
set ARGSall=%*
set "ARGSxall=%*"
set ARGS_9=%9
set "ARGS_x9=%~9"
set ARGS_1=%1
set "ARGS_x1=%~1"
echo $[0x00]"$[0x0F]ARGSall$[] =$[0xF0]%ARGSall%
echo $[0x00]"$[0x0F]ARGSxall$[]=$[0xF0]%ARGSxall%
echo $[0x00]"$[0x0F]ARGS_9$[]  =$[0xF0]%ARGS_9%
echo $[0x00]"$[0x0F]ARGS_x9$[] =$[0xF0]%ARGS_x9%
echo $[0x00]"$[0x0F]ARGS_1$[]  =$[0xF0]%ARGS_1%
echo $[0x00]"$[0x0F]ARGS_x1$[] =$[0xF0]%ARGS_x1%
endlocal
goto :eof

Attached Files

  • Attached File  ARG.zip   836bytes   133 downloads


#35 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 03 November 2022 - 11:20 PM

I found other unexpected behavior regarding use of %~1 after a call without and with operators after the call, so on same line:

ARGOK.G4B_test_complex_argument_after_call_without_and_with_operators_behind.png

BTW case if variable used as argument is between double-quotes

So operator ';;' is not the same as a new line in this case.

#36 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 04 November 2022 - 09:24 AM

So %* has an extra space at the end ???

 

but %9 and others seems OK if you use

 

echo @%9@

 

to show the presence of a space or not

 

So some of your problem is caused by using the echo $[0xF0]%~9  syntax which is showing at space at the end whereas echo @%9@  does not show a space

Attached Thumbnails

  • argtest.JPG


#37 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 04 November 2022 - 11:43 AM

I have reported two new bugs here
https://github.com/c...grub4dos/issues

#38 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 04 November 2022 - 02:21 PM

Thanks for bug-reporting.

 

Even '00' after 'empty' echo $[0xF0], I never expected... :blink:

 

To make myself more clear about 'behavior' '%9':

  • If my 'complex' variable %ARG% is on command-line: no space behind with '%9'
  • If my 'complex' variable %ARG% is on command-line and line with call is call :conv %* (no double-quotes around) the line in subroutine ':conv' with '%9' gets one space behind (while %* gets an extra space behind)
  • If an echod line with '%9' (with echo $[0xF0]%9) in subroutine ':conv' showed just one space in my earlier print-screens, this is because '%9' didn't exist actually in such a case - so just the same as issue #385 you just reported. To me it seems '%9' is fully correct

-------------------------------------------------------------------------------------------------------------------------------------------

 

I tested problem of echo $[0xF0] with my tool KEYBUFF.G4B

In grub4dos' History Buffer there is nothing special (nor with ARG.G4B STRING: %ARG%).

 

KEYBUFF.G4B menu 'V' no extra space after ARG.G4B STRING- %ARG% nor extra '00' after 'empty' echo $0xF0 I.jpg



#39 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 04 November 2022 - 09:59 PM

I am afraid new grub4dos version 20221026 is not fully 'good'.

 

After a run while working on next version of my intermediate project Fn11.G4B I saw this:

 

Fn11.G4B v0.2 x22 '%ARG%' OKE=found dbq I.jpg

 

On the echo-lines '3' and '10' echo starts at horizontal position '2' instead of position '1' (position '1' because of use of hidden double-quote sign in my script, for instance for third line I just wanted to edit a bit:

 

echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%ARG2%

 

Never saw this before, so a quick test of last version I was using (20220915) against the new version (20221026):

 

echo $0x0FARG1 starts at horizontal position 0 grub4dos version 20220915 OKE I.jpg echo $0x0FARG1 starts at horizontal position 1 instead of 0 NOT OKE grub4dos version 20221016 III.jpg

 

Version 20220915 echos with color code as expected, but there seems to be some problem with new version 20221026. :ph34r:



#40 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 06 November 2022 - 09:27 AM

Try glrdr new version

https://github.com/c...4dos/issues/385

If still a problem pleas provide a simple .g4b file which shows ONLY the problem.



#41 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 06 November 2022 - 11:44 AM

Tested on Limbox86, so Qemu

 

Screenshot_20221106-122731.png

!BAT
#-#+ TESTECHO.G4B v0.1 (20221106), by deomsh
#-#+ Function: test behavior of echo with $[] color codes
echo ARG1
echo $[0x0F]ARG1
echo $[0xF0]ARG1
echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
echo $[0x0F]ARG1 ;; echo $[0xF0]ARG1
echo $[0x0F]ARG1$[] ;; echo $[0xF0]ARG1
echo $[0x07]ARG1
echo $[]ARG1
echo $[]ARG1 && echo $[0x07]ARG1
echo $[0x1F]ARG1
echo $[0xF1]ARG1

Attached File  testecho.zip.txt   294bytes   115 downloads

 

 



#42 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 06 November 2022 - 12:00 PM

echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%

This line seems OK it is printing a black character on a black screen would just produce a black space

 

but in graphicsmode 3 it seems there is a problem with it starting to print in column 1 rather than column 0.

 

if you try

graphicsmode -1 800

then it seems OK ???

I have reported issue



#43 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 06 November 2022 - 08:50 PM

Graphicsmode is oke (grub4dos version 20221026 - tested in Vbox)

By the way, code-line:

echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%

is NOT good in console-mode, still an extra space.



#44 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 07 November 2022 - 07:02 PM

I tested GRLDR version 20221107 as published today in thread of Issue #381: https://github.com/c...4dos/issues/381

 

On Limbo x86, so QEMU

 

In graphicsmode 0x142 everything seemed ok (with scrolling too):

 

Screenshot_20221107-154413.png Screenshot_20221107-154459.png

 

But NOT in console mode however WITH scrolling:

 

Screenshot_20221107-154235.png Screenshot_20221107-154259.png

 

In Virtual Box same (with earlier script TESTECHO.G4B):

 

echo $-BUG GRLDR 20221107 graphicsmode 0x142 TESTECHO.G4B OKE I.jpg echo $-BUG GRLDR 20221107 graphicsmode 0x142 TESTECHO.G4B OKE afterscrolling II.jpg echo $-BUG GRLDR 20221107 consolemode TESTECHO.G4B OKE I.jpg echo $-BUG GRLDR 20221107 consolemode TESTECHO.G4B BAD ofter scrolling II.jpg

 

 

It seems the echo bug with 'highlight + scrolling' is still there (or again???) on Virtual Box.

To me it seems the problem is only actual now if there a more chars to echo than will fit in one line (minus one!).

Watch the position of '[]' inside '$$$$$$$$$$$$' in the last print-screen:

 

echo $-BUG GRLDR 20221107 graphicsmode 0x142 + higlight color STILL BAD in Vbox after scrolling if $ after collumn 79 III.jpg

 

BTW last print-sceen above is in graphicsmode 0x142. :ph34r:

 

 

I Limbo x86 I made a fresh test-file with some more demanding echos (used only in first four print-screens above):

!BAT
#-#+ TESTECHO2.G4B v0.2 (20221107), by deomsh
#-#+ Function: test behavior of echo with $[] color codes
debug 1
set /a version=*0x8278 > nul
echo Grub4dos version %version%
graphicsmode
pause --wait=0 "echo ARG1
echo ARG1
pause --wait=0 "echo $[0x0F]ARG1
echo $[0x0F]ARG1
pause --wait=0 "echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
pause --wait=0 "echo -n $[0x0F]ARG1 && echo $[0xF0]ARG1
echo -n $[0x0F]ARG1 && echo $[0xF0]ARG1
pause --wait=0 "echo -n $[0x0F]ARG1$[] && echo $[0xF0]ARG1
echo -n $[0x0F]ARG1$[] && echo $[0xF0]ARG1
pause --wait=0 "echo -n $[0x08]ARG1 && echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
echo -n $[0x08]ARG1 && echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
pause --wait=0 "echo -n $[0x08]ARG1$[] && echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
echo -n $[0x08]ARG1$[] && echo $[0x00]"$[0x0F]ARG1$[]=$[0xF0]%^ARG1%
pause --wait=0 "echo -n -e $[0x08]ARG1\x20 && cat --skip=5 --length=46 /%0
echo -n -e $[0x08]ARG1\x20 && cat --skip=5 --length=46 /%0
pause --wait=0 "echo -n -e $[0x08]ARG1\x20$[] && cat --skip=5 --length=46 /%0
echo -n -e $[0x08]ARG1\x20$[] && cat --skip=5 --length=46 /%0

Attached File  TSTECHO2.ZIP.txt   435bytes   115 downloads



#45 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 13 November 2022 - 10:12 PM

I 'finished' my intermediate project Fn11.g4B which can be used as replacement for call Fn.11 if needed.

 

I thankfully used steve6375's directives, but not all: my final result is intended to be one-to-one to call Fn.11.

 

To avoid double-quote-with-spaces related problems I switched the order of arguments: STRING is coming last, FIND first (watch: double-quote-with-spaces related problems can still exist in argument FIND).

 

I added ONE switch for not-case-sensitive search, OR with direct access to 'cat --locate' (or cat --locatei).

 

First print-screen gives some statistics of the script, including if taken out for use as sub-routine:

 

TEXTSTAT.G4B Fn11U.g4B and Fn11sub.txt VI.jpg

 

Some 'action' print-screens to see operation of the script:

 

Fn11U.g4B big substring in bigger string without and with i-switch (char22 replaced by x13) I.jpg Fn11U.g4b with various replacements for double-quotes up to x1F exists II.jpg

 

To get an impression about speed I did some looptests:

 

LOOPTEST num 1000 runs 4 compare NormFn11.g4b StevFn11.g4b Fn11.g4b (version 0.3) with x21abc a IV.jpg LOOPTEST num 1000 runs 1 compare StevFn11.g4b Fn11U.g4b (version 0.3) with @x22 x22 and switch -i V.jpg

 

If my utility LOOPTEST.G4B (unpublished) is right, the original call Fn.11 is incredibly fast. :wacko:

 

However: every cat-statement will cost about 500 ms per thousand loops (tests in Virtual box).

 

To gain some speed I cheated a bit and didn't use call F.11 to find double-quote chars or \x22 in STRING, if FIND is solely \x22. Same for \x00 to find \x00 in STRING (I presume 'real' char 00, or NULL-character, will not exist in a variable). So less cat-statements. :rolleyes:

 

BTW STEVFN11.G4B has the same 'core' as steve6375's, but (more or less) same code-lines as Fn11.g4b to pick-up the arguments from the command-line. :ph34r:

 

A readme is included, see: https://github.com/deomsh/Fn11.g4b



#46 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 17 November 2022 - 09:50 PM

I did some tests of Fn11.g4b to see how more complex strings are processed.

 

In the readme is mentioned 'Remark6: If FIND contains spaces near ' " ' or '\x22' use instead of spaces always '\x20'. Use for '%' '\x25', for ' | ' ' \x7C ' or '\x20|\x20', so I asked myself how this will be if STRING contains grub4dos code-lines, which have always spaces around operators?

 

First argument FIND is in full control of the user (unless to test if FIND is an unknown sub-string of STRING - I never used call Fn.11 in this way so far). But STRING is partial or fully unknown, otherwise there was no need for call Fn.11. :lol:

 

For more smooth handling of grub4dos-operators surrounded with spaces I experimented a bit with replacing first and last space in a command-line argument for ASCII-code '\x20'.

 

I tested for following (nonsense) code-lines in FIND and STRING:

 

Fn11db3.g4b v0.3.1_dbg better handling of spaces around grub4dos operators I.jpg

 

As can be seen is with first test in print-screen above replacing spaces by \x20 successful for FIND.

Second test shows no problem finding substring FIND in STRING.

 

BTW numbering of ARG's is according their final position in call Fn.11 "%ARG1%" "%ARG2%", remember in my script first argument FIND is same as ARG2 in the final Fn.11-call. :ph34r:

 

                                      >>>>>>>>>>>> | <<<<<<<<<<<<

 

But as soon 'set'-statements use double-quotes around i ran into problems. The last =-char in ' ;; set "a=f"" ' is not found anymore on the command-line, not even by %*. As can be seen with first test %1 reads up to ' set "a ' while %2 reads last part ' f"" '. The =-char becomes the dividing space. Second test in print-screen below shows replacing these double-quotes by \x22 gives no problem anymore regarding reading out the =-char, but this can not be done after a read-out of STRING from the command-line:

 

Fn11db3.g4b v0.3.1_dbg limits with = between dbq's II.jpg

 

I like universal solutions, so I thought maybe an extra pair of double-quotes around STRING could solve my problem, but this seems to be a fully wrong idea. :(

 

So just for the record the results (second and third test in print-screen below):

 

Fn11db3.g4b v0.3.1_dbg limits with STRING between 2 x dbq's III.jpg

 

Behavior of %1 and %2 make sense to me, but %* ? :blink:

 

Any ideas?

 

 

 

 

 

 



#47 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 20 November 2022 - 12:16 PM

I found no solution for the %*-read-out from command-line of ' ;; set "a f"" ' instead of ' ;; set "a=f"" ' (missing =-char). :(

I even tried to read-out the whole command-line with call Fn.78 to compare, but this (undocumented??) call needs extra user input before, and the 'output' I found does not seem usable in script Fn11.g4b.

 

However, I made some changes for better read-out of FIND and STRING from command-line. Version 0.3.1 of Fn11.g4b is ready for download: https://github.com/d...ases/tag/v0.3.1

 

In next print-screen difference can be seen, less need to use \x20 instead of spaces in FIND. And in same critical case STRING will not crash:

 

Fn11.g4b Fn11v31.g4b COMPARE v0.3 & v0.3.1 = better handling of spaces around grub4dos operators + difference showed with TEXTSTAT.G4B v0.7R VII.jpg

 

Last lines in print-screen above shows difference in 'healed' code-line for case of STRING.

Also a preview of coming next version of TEXTSTAT.G4B with the /P-switch to print lines containing

found 'phrase' of "/COUNT:phrase" (steve6375 asked for this possibility).

 

All in all I reduced number of if-statements from 91 to 89, script seems almost 0.4% faster now. See next print-screen:

 

LOOPTEST FN11.G4B vs FN11V31.G4B - 0,38% faster, two 'if-statements' less I.jpg

 

BTW sample is only 10 runs of 10,000 tests :ph34r:



#48 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 23 November 2022 - 02:11 PM

TEXTSTAT.G4B version 0.7 is ready for download. Readme and Bonus-script VERSION.G4B included: https://github.com/d...leases/tag/v0.7

 

I added switches steve6375 asked for. Also added switch for quiet operation.

 

New features in v0.7:

Count of lines starting with space
Added switch /V to export all counts as variables
Added switch /Q for quiet operation and export counts as variables
Added switch /P to print counted lines containing 'phrase' to screen
Better handling of first line of text-files
Refuses FILE containing '%'
Switch /MDBASE:startsector exits if below 0x3000

 

BTW I reversed order of switches and FILE because number of switches needs an extra subroutine now, and I found it easier to parse command-line in this way.

 

Action print-screens of export of counts with switches /V and /Q:

 

TEXTSTAT.G4B v7.0 with new switches -V, -Q and -COUNTc I.jpg

 

BTW: names of variables are in same order as counts printed (after set * !).

BTW2 I added example of use of /COUNTc: instead of /COUNTC: - not new in V0.7 (switches were already not case-sensitive), but maybe better readable.

 

Next print-screen shows quiet operation of "COUNTc: if "  with extra switch /Q - only variable 'result' is exported, with number of counted phrases.

Also shown counting spaces at begin of line and better support of first line in text-files. Last lines show use of /P switch to print line containing counted phrase to screen and error handling of not-supported char:

 

TEXTSTAT.G4B v7.0 with combi  -Q and -COUNT and show support of LFN, swows spaces at begin of line and handling of line 1 III.jpg

 

BTW spaces on line 0001 can even counted manually :rolleyes:

If someone wants another color for the line-numbers: just edit Line 358.

 

Last print-screen show possible usability of switch /P (so far only together with switch ["][/]COUNT[c]:phrase["]):

 

TEXTSTAT.G4B v7.0 with new switch -P to print -COUNTc-phrase _BONUS two uses of VERSION.G4B II.jpg

 

BTW last two line shows the two uses of BONUS-script VERSION.G4B

 

Personal note: I was a bit sceptic if I could 'script' steve6375's idea of printing counted phrases to screen, but it was do-able (even with a relatively small subroutine).

I was surprised of the usability of printing lines TOGETHER on screen containing found 'phrase'. Much easier to compare more or less look-alike scripting lines. :)

I never used a utility with this possibility, except the left pane of MSWord with use of Ctrl+F. :ph34r:

 

BTW I used counting of EndOfLine markers, these must be same in whole text-file in my approach. Cases of 'mixed' EOL's are not a problem for counting as such, but printing to screen will be disabled.

Normally such text-files will not exist, unless a MS-DOS text-file is edited in an Unix-environment on an editor like the built-in one of 'Total Commander for Android'. :(



#49 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 26 November 2022 - 11:24 PM

Something went wrong: Post doubled. Please delete this one.

#50 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 26 November 2022 - 11:25 PM

There were Issues raised concerning TEXTSTAT.G4B

 

Next version is ready, with some extras: https://github.com/d...ases/tag/v0.7.2

 

v0.7.2
Interrupt [Hit Q...] is working to abort further printing to screen of lines containing counted 'phrase' and exit script
Highlighting of each 'phrase' inside lines printed to screen

v0.7.1
Correction of Examples in Help: FILE comes before switch(es)

 

BTW only highlighted printing of full color codes is not possible (only the extra '$'). If still wanted, omit for instance the '$' in $[0x00], or last ']'. Also COUNT:\x20$[ with switch /P can be useful.

 

 

Second bonus-file included:

 

PAGESTAT.G4B to read-out graphicsmode, number of chars per line, number of lines per screen and total number of chars per screen:

 

PAGESTAT.G4B console mode I.jpg PAGESTAT.G4B mode -1 800 II.jpg PAGESTAT.G4B mode -1 (max in VBox) III.jpg

 

BTW: screen will always scroll ONE line, behavior of script is by default. :unsure:







Also tagged with one or more of these keywords: grub4dos, scripting

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users