Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: sci.crypt
Subject: Re: The lost key
Date: Sun, 30 Mar 2025 12:52:15 -0700
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <vsc7dg$28n4g$2@dont-email.me>
References: <1813d36bbf.1743292001@ejjjn.mw> <406894c176.1743293683@lmhhi.zx>
 <vsa8ps$2rbg7$1@dont-email.me> <vsahdt$358a2$2@dont-email.me>
 <vsal3v$3anr9$3@dont-email.me> <vsbq3v$1qfti$2@dont-email.me>
 <AABn6XjYgEAAAD+a.A3.flnews@o15.ybtra.de> <vsc1ul$23hnc$1@dont-email.me>
 <20250330su183914@o15.ybtra.de> <vsc69b$27l0j$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 30 Mar 2025 21:52:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fb31161437cb09e11ca695b7d5812c51";
	logging-data="2382992"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qEAaDsHajr66eP0h96xEm60yH2uoCToM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sivdAJbhHxtUBnIWMMKZPt6K1cs=
Content-Language: en-US
In-Reply-To: <vsc69b$27l0j$1@dont-email.me>

On 3/30/2025 12:32 PM, Rich wrote:
> Marcel Logen <333200007110-0201@ybtra.de> wrote:
>> Rich in sci.crypt:
>>
>>> Marcel Logen <333200007110-0201@ybtra.de> wrote:
>>>> Rich in sci.crypt:
>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>
>> [...]
>>
>>>>> No, you have now /discovered/ that "the command shell" interprets some
>>>>> characters itself, and not passing them through to the command.
>>>>
>>>> Perhaps he uses the "here documents" feature of the shell.
>>>
>>> That is possible, but even so, there's two versions of here docs, one
>>> that interpretes shell metacharacters and one that does not.  Using the
>>> 'interpreting' variant would produce the same results.
>>                               ^ not (?)
> 
> The word 'same' there was referring to the output Chris received,
> although looking it over now, that was also an ambigious back
> reference.
> 
>> | user15@o15:/tmp$ ./scos2-ok e 55 77 <<"EOF"
>> | > Hello World, this is a test. And I will see what happens.
>> | > EOF
>> | !(8sf <|#5h[ R@&9 jd > \86r( 7@4 T rNA[ *mW Y?"^ mPO\$5u+
>> |
>>
>> | user15@o15:/tmp$ ./scos2-ok d 55 77 <<qqqq
>> | > !(8sf <|#5h[ R@&9 jd > \86r( 7@4 T rNA[ *mW Y?"^ mPO\$5u+
>> | > qqqq
>> | Hello World, this is a test. And I will see what hapOXc_
>> |
>>
>> | user15@o15:/tmp$ ./scos2-ok d 55 77 <<"qqqq"
>> | > !(8sf <|#5h[ R@&9 jd > \86r( 7@4 T rNA[ *mW Y?"^ mPO\$5u+
>> | > qqqq
>> | Hello World, this is a test. And I will see what happens.
>>
>> man bash, chapter "Here Documents":
>>
>> | If any part of word is quoted, the delimiter is the
>> | result of quote removal on word, and the lines in the
>> | here-document are not expanded.  If  word  is
>> | unquoted,  all lines of the here-document are
>> | subjected to parameter expansion, command substitution,
>> | and arithmetic expansion, the character sequence
>> | \<newline> is ignored, and \ must be used to quote
>> | the characters \, $, and `.
>>
>> "word" is here "EOF" or "qqqq".
> 
> We (you and I) do not know:
> 
> 1) if chris was even using here docs -- he *might* very well be trying to
> pass SCOS input via a CLI parameter;
> 
> 2) in the case he was using here docs, we don't know which one he used
> -- if he used the unquoted version, then it is likely at least one meta
> character was consumed by the unquoted here doc
> espansions/substitutions, and if that happens, all characters after
> that point become garbled.
> 
>> The \ quotes the $ sign before the 5 in the qqqq
>> version.
> 
> Yes, one can escape the metacharacters in the unquoted here doc
> version.  But, under the assumption Chris was using here docs, did Chris
> perform the escaping, and perform the escaping correctly?
> 

I am using the damn command line from windows:

Microsoft Windows [Version 10.0.26100.3476]

Yikes! ;^o