[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <658670d0-086b-49e9-85ac-3e002fa8322b@linuxfoundation.org>
Date: Tue, 15 Apr 2025 17:03:44 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Mark Rutland <mark.rutland@....com>, Mark Brown <broonie@...nel.org>,
linux-kselftest@...r.kernel.org, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] selftests/ftrace: Differentiate bash and dash in
dynevent_limitations.tc
On 4/15/25 16:58, Masami Hiramatsu (Google) wrote:
> On Mon, 14 Apr 2025 21:09:00 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
>> From: Steven Rostedt <rostedt@...dmis.org>
>>
>> bash and dash evaluate variables differently.
>> dash will evaluate '\\' every time it is read whereas bash does not.
>>
>> TEST_STRING="$TEST_STRING \\$i"
>> echo $TEST_STRING
>>
>> With i=123
>> On bash, that will print "\123"
>> but on dash, that will print the escape sequence of \123 as the \ will be
>> interpreted again in the echo.
>>
>> The dynevent_limitations.tc test created a very large list of arguments to
>> test the maximum number of arguments to pass to the dynamic events file.
>> It had a loop of:
>>
>> TEST_STRING=$1
>> # Acceptable
>> for i in `seq 1 $MAX_ARGS`; do
>> TEST_STRING="$TEST_STRING \\$i"
>> done
>> echo "$TEST_STRING" >> dynamic_events
>>
>> This worked fine on bash, but when run on dash it failed.
>>
>> This was due to dash interpreting the "\\$i" twice. Once when it was
>> assigned to TEST_STRING and a second time with the echo $TEST_STRING.
>>
>> bash does not process the backslash more than the first time.
>>
>> To solve this, assign a double backslash to a variable "bs" and then echo
>> it to "ts". If "ts" changes, it is dash, if not, it is bash. Then update
>> "bs" accordingly, and use that to assign TEST_STRING.
>>
>> Now this could possibly just check if "$BASH" is defined or not, but this
>> is testing if the issue exists and not just which shell is being used.
>>
>
> Thanks for fixing this issue!
>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
>
Steve, do you want me to pick this up for rc3?
thanks,
-- Shuah
Powered by blists - more mailing lists