am i going crazy? WHY CAN'T I PASS %1 SUCCESSFULLY

[Claire_CJS]

I passed my first batfile parameter in 1988, why am I failing to do it now?

Literally, I am calling my own AskYN.bat file like this (and echo'ing the call to the screen first, just to be sure it's right):

And AskYN.bat starts right off with capturing the %1 parameter which I echo immediately afterward — sample output below:

Yet... "Delete the original archive" is not being successfully passed as %1

HOW IS THIS POSSIBLE?!?!?!
i feel like i'm going crazy.
something is very fundamentally wrong with this situation.


I've lost over an hour on this.


So this is what happens.... As you can see, askyn is called with a first parameter .... and somehow that first parameter, when received, is the name of the archive I just unpacked with 7z.exe and not the "Delete the original archive" that is passed!

How the heck is %1 being overridden? This makes no sense.

this should never happen
it's... impossible for this to happen
but it's happening, so it's not impossible

how is this happening?!

i can't fix it because there's no sense to this


It feels like 7z.exe is somehow causing parameter passing to not work after being called... So i included my 7z.exe [which succeeds with many .7z archives that the internal 7z command fails with]

 

[Claire_CJS]

This is the single most frustrating bat file mystery i've run into in years, if not ever.

 

[vefatica]

Can you reproduce it? Can you make it any simpler? This seems OK.

v:\clio> type bat1.bat
touch /q /c foo.txt
d:\7zip\7z.exe a foo.7z foo.txt > nul
del /q foo.txt
d:\7zip\7z.exe e foo.7z > nul
call bat2.bat "a b c" d

v:\clio> type bat2.bat
echo %%1 = %1
echo %%2 = %2

v:\clio> bat1.bat
%1 = "a b c"
%2 = d

v:\clio>

 

[Claire_CJS]

oh it's not happening anywhere except where it's happening, if that makes sense!

I for the life of me can't understand how a context could even do that.

 

[Claire_CJS]

Like, if i call it directly, it works just fine.

I honestly think I've uncovered some weird kind of bug here.

There's NO REASON that the first parameter should magically morph into a value that was never even passed as a parameter.

It's a very holistic set of scripts. Yet, in the end, i am echo'ing a call before calling a bat with a specific parameter, yet %1 of the called bat is not the parameter passed to it.

It's the most insane thing i've seen in 35 yeras of scripting, to be honest.

I'm going to have to edit my script to receive parameter via environment variable becuase PASSING IT IS NOT WORKING.

And I don;'t know why.

I could bypass this in 5 minutes, but i've now spent 2 hours because I WANT TO KNOW WHY, i want to figure this out and report whatever bug it may be to whoever may need it reported to them.

 

[Charles Dye]

Is it only batch files, or is there maybe an alias in there somewhere?

 

[Claire_CJS]

I only use globally applied aliases, and that still wouldn't explain this.

I echo the call prior to calling it, i call it with a value, i fetch that value on the 1st line... and it's not the value passed.

 

[Claire_CJS]

It's actually a script i've been using (but updating lately) for 10+ yrs to unzip every archive in a folder. I wanted to add a yes/no prompt for deleting the archive, and i used my standard askyn.bat which is also heavily integrated into all of my stuff. Works just fine.

I added 7zip functionality to that same script rather recently.

I do think 7zip is doing something spooky. No real way to prove it, and it seems to defy expectations of how software is supposed to work.... But I've seen some things and at this point will believe anything.

 

[Claire_CJS]

I'm going to try %[1] instead of %1 and see if that somehow avoids it.

 

[Alpengreis]

@ClioCJS

Can you agree that this doesn't happen if you use (just for testing) the internal 7z instead of the external 7z.exe?

 

[Claire_CJS]

@ClioCJS

Can you agree that this doesn't happen if you use (just for testing) the internal 7z instead of the external 7z.exe?

Good call! That would verify my suspicions.

And. Wow.

It works as intended with *7unzip

7z.exe definitely does something so that %1 fails immediately afterward
[but also runs quite faster than the internal one]

this is crazy. how is that even possible?
kicker is: it still happens even if you kill any 7z.exe process. The process isn't running, but somehow, it breaks %1 passing immediately afterward.

What. The. ........................

This has to be some kind of bug.

 

[Charles Dye]

How are you calling 7z.exe? Are you using the full pathname, or a path search? Or maybe an alias?

 

[Claire_CJS]

Admittedly i'm just calling it with '7z' not explicitly 'c:\util\7z.exe'

but in the end, this seems to be the difference:

In whether the following line works (passes %1 successfully) correctly:

Yea. That seems to be the crux of it.

VERY curious.

It almost feels like there are 2 bugs at work:

1. 7z.exe should not be doing that monkey business with "locking" %1 with it's magic voodoo powers that neither 7z.exe, nor any process, should ever possess
2. tcc.exe should not be allowing this to be done to it

And it's not like it's some old arcane version of 7z.exe either. If anything, it's almost too new, if it's doing **** like this ...

 

[Alpengreis]

WEIRD, really!

I saw that different bugs in 7z are fixed in beta versions (since release v23.01). Unfortunately I have no details about - however: you COULD try with the newest beta v24.04 ... who knows ...

 

[Charles Dye]

I am trying to reproduce this behavior:

C:\Test>which 7z
7z is an external : C:\Bin\Util\7z.exe

C:\Test>type test1.btm
@echo off
setlocal

set USE_7Z=1
set TO_UNZIP=c:\test\test.7z

call test2.btm Foo Bar Fum

if %USE_7Z eq 1 ( 7z x -aoa "%TO_UNZIP" )

call test2.btm Foo Bar Fum

endlocal

C:\Test>type test2.btm
@echo off
echo %%1 = [%1]
echo %%2 = [%2]
echo %%3 = [%3]
echo %%4 = [%4]

C:\Test>test1.btm
%1 = [Foo]
%2 = [Bar]
%3 = [Fum]
%4 = []

7-Zip 23.01 (x86) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20

Scanning the drive for archives:
1 file, 9771 bytes (10 KiB)

Extracting archive: c:\test\test.7z
--
Path = c:\test\test.7z
Type = 7z
Physical Size = 9771
Headers Size = 411
Method = LZMA2:48k
Solid = +
Blocks = 1

Everything is Ok

Files: 13
Size:       37722
Compressed: 9771
%1 = [Foo]
%2 = [Bar]
%3 = [Fum]
%4 = []

C:\Test>

I'm not seeing 7ZIP cause an issue with batch parameter passing.

 

[Claire_CJS]

I'm not seeing 7ZIP cause an issue with batch parameter passing.

I imagine there are other forces at work, but it's definitely something with 7z.exe the likes of which i've never witnessed and which does not seem to be able to be bypassed. The entire parameter chain gets corrupted. It actually propagates down to other BAT files too -- my beep.bat ends up getting passed the archive name 7z.exe was working with instead of the frequency i pass to it, and throws an error that it's not given a frequency (i added my own layer around the internal beep command awhile back).

I'm going to end up having to modify my BAT to take the first parameter via optional environment variable to get around this.

 

[Claire_CJS]

Okay, I think I figured out what is happening

I did some things wrong. But that wrongness never impacted things this way before!

I was running a for loop

but instead of saying:

for %var in (*)

i was saying:

for %1 in (*)

this works fine and dandy this way on the command line. But somehow, using that variable in the for loop replaces %1 as subordinate bat files call other subordinate bat files. I do not think it should work this way, I think %1 should always use the locally scoped parameter that is passed. And I honestly feel like that's a bug, but not one that anybody is ever going to fix because it's a bug that only manifests when the real bug is me, doing things incorrectly haha

I feel pretty stupid though I'm glad we got to the bottom of this, I don't think I would have without the encouragement and scrutiny here.

I'm confused how this never happened before, but oh well! :)

 

[Charles Dye]

i was saying:

for %1 in (*)

I'm amazed that that's legal!

 

[Alpengreis]

Thanks for sharing with us, Claire!

 

[Claire_CJS]

I'm amazed that that's legal!

Right? At some point my brain just forgot how to do it right. This was the first time I suffered consequences for it though!

It maybe... shouldn't be legal?

 

[AnrDaemon]

Technically, this is legal. The consequence is the usual one from redefinition of the variable.