[Intel-gfx] [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Jani Nikula]

On Wed, 12 Oct 2016, David Weinehall <david.weinehall at linux.intel.com> wrote:
> On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
>> On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
>> > The "change" to use bash just reflects current reality. All the changes
>> > here look simple and sane, and immediately improve the results. The work
>> > is already done, no use blocking them because someone might eventually
>> > rewrite them in C. (And it will be a PITA to write the module reload
>> > test in C, so I wouldn't hold my breath.)
>> > 
>> 
>> The scripts are really simple, most of the scripts even use POSIX sh
>> compliant constructs but just the wrong shebang. And sometimes some a
>> advanced bash feature here and there which could be replaced easily.
>> 
>> > For the series,
>> > 
>> > Reviewed-by: Jani Nikula <jani.nikula at intel.com>
>> > 
>> > 
>> > PS. When I look at IGT and the macro/setjmp/longjmp magic to create the
>> > test/subtest/fixture infrastructure, making the tests look like they've
>> > been written in some extended version of C, I have to question whether C
>> > really is the right language for the tests. libdrm python bindings and
>> > python, anyone?
>> 
>> My patches to convert away from bash were to allow running the tests in
>> minimal initramfs environment where the kernel + IGT would be a
>> standalone bzImage suitable for netbooting, but we can go to another
>> direction too, and lets add Java as runtime requirement for I-G-T!
>> 
>> Regards, Joonas
>> 
>> <plaintext>I'm against converting to bash/python for no
>> benefit.</plaintext>
>
> +1, Insightful.
>
> Most of the bashisms seem to be simple cases of the superfluous
> "function" in front of functions...

The point here was that the scripts were *already* de-facto bash scripts
and would not have worked on a pure Bourne shell /bin/sh.

For generic scripts I'm fine with striving to keep them free of
bashisms, but at the same time for rather dedicated scripts which
already have a set of specific/non-trivial dependencies, I really can't
be bothered.

If you really care, go ahead and send the patches to make these Bourne
shell compatible, but then do also sign up for testing them on non-bash
shells. The CI won't. I don't think it's worth the trouble, but YMMV.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center