Script Executor wont save with #!/bin/bash #!/bin/sh

[Sifu Tian]

Hi,

I'm sure this is an old issue however I cant seem to find the resolution.

I have a script executor with a job that is running a python module defined for shellcheck linter.

The pipeline fails with return error:

'message': "Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.", 'fix': None}

It's looking for a shell in the script executor which I thought would be self contained.

While attempted to add #!/bin/sh, it wont allow me to save and generates the error:

"There was an unknown error performing the operation. Possible reason ()"

If I try with just the customer command option I get this error when adding #!/bin/sh:

There was an unknown error performing the operation. Possible reason ()
Error when processing params for '#!/bin/sh' used in field 'argListString', # must be followed by a parameter pattern or escaped by another #.

I also found this very old close issue which is a similar issue I'm having.

https://github.com/gocd/gocd/issues/817

Any help would be great.

[Sriram Narayanan]

On Tue, May 10, 2022 at 11:45 AM Sifu Tian <sifutia...@gmail.com> wrote:

Hi,

I'm sure this is an old issue however I cant seem to find the resolution.

I have a script executor with a job that is running a python module defined for shellcheck linter.

Could you use the Custom Command to run a shell script instead?

That way, all your actions would be within a shell script that you can test and store in version control, and then check out and use as a material.

https://docs.gocd.org/current/configuration/admin_add_task.html

I have not used this task executor plugin since I have always relied on the Custom Command approach above.

 

The pipeline fails with return error:

'message': "Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.", 'fix': None}

It's looking for a shell in the script executor which I thought would be self contained.

While attempted to add #!/bin/sh, it wont allow me to save and generates the error:

"There was an unknown error performing the operation. Possible reason ()"

If I try with just the customer command option I get this error when adding #!/bin/sh:

There was an unknown error performing the operation. Possible reason ()
Error when processing params for '#!/bin/sh' used in field 'argListString', # must be followed by a parameter pattern or escaped by another #.

I also found this very old close issue which is a similar issue I'm having.

https://github.com/gocd/gocd/issues/817

Any help would be great.

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/930eef05-427e-413c-9ccd-ee8494b47d86n%40googlegroups.com.

[Sifu Tian]

HI,

Ive tried both.  You can see the second screenshot is the custom command method.

Both ways don't allow you to save the task if you add #!/bin/sh to the argument and throw and error.

[Sriram Narayanan]

On Tue, May 10, 2022 at 1:40 PM Sifu Tian <sifutia...@gmail.com> wrote:

HI,

Ive tried both.  You can see the second screenshot is the custom command method.

Ah indeed!

Both ways don't allow you to save the task if you add #!/bin/sh to the argument and throw and error.

Could you replace the #!/bin/bash with the shell script name instead? The contents of that text box and the arguments are used as parameters for a Java exec() call.

So, your custom command would be just myscripts/linterscript.sh (where linterscript.sh would be committed as executable when committing to git, and would have #!/bin/bash at the top

-- Sriram

 

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/6378d084-2461-4007-bd42-3c236c284ea1n%40googlegroups.com.

[Sifu Tian]

Hi Sriram,

The script is a python module with Shellcheck linter embedded.  I can't wrap that module into a linterscript.sh without breaking up all the modules that are linked to it.

If the custom command or the script executor is a shell, shouldn't the task read it just like I call it from a command line?  It doesn't and it triggers and error as stated above:

The pipeline fails with return error:

'message': "Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.", 'fix': None}

Is there a way to add a shebang which would correct this issue?

Thanks for your help.

[Chad Wilson]

While the not-so-helpful error messages from GoCD aren't great - I'm not sure this is the root of your problem? The original error you said you were trying to fix is a pipeline failing with

'message': "Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.", 'fix': None}

This is an error message from the shellcheck tool itself about the script it is checking/linting. It shouldn't be complaining about the environment it is running in. It is telling you that it can't lint/check the script, since it's not sure which semantics/rules to apply on the individual script it is checking (its target shell). See https://github.com/koalaman/shellcheck/wiki/SC2148

Can you check the specific file/script shellcheck is looking at when the pipeline is failing and make sure it has a shebang? Unless you are running shellcheck and checking the dynamically generated temporary scripts GoCD generates (seems unlikely) I'm not sure the root problem you are trying to solve is with GoCD, and instead is somewhere else.

Chad

PS: The second attempt is failing because # is a special character in GoCD land, used for parameter substitution. This might also be why the script executor plugin is failing, but not 100% sure- can you get a stack trace or other error details from the GoCD server logs and perhaps I can take a look?

As the second error tries to tell you, to get past the parameter substitution you would probably need an extra hash i.e ##!/bin/sh

However even if you get past these errors, I don't think either option will change the shell because in the two styles

• script executor plugin runs "/bin/bash -c YOUR_SCRIPT"
• custom command just runs it as if you entered arguments on the command line directly to a bash process, so you'd need a -c argument, and then a line with YOUR_SCRIPT similar to the "syntactic sugar" the script executor plugin gives you.

I'm not sure it'd make a lot of sense to add a shebang in either case...

On Tue, May 10, 2022 at 1:40 PM Sifu Tian <sifutia...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/6378d084-2461-4007-bd42-3c236c284ea1n%40googlegroups.com.

[Sifu Tian]

Hi Chad,

Thanks for the info, it was very helpful.  I can call the python module outside of GoCD and it works fine so I was scratching my head why it would not work inside the script executor.

What's also strange is that Shellcheck (SC2148) indeed has that message/error) however, that specific SC isn't being leveraged in my Shellcheck linter.

What I did do is ignore the check until I can determine the best path forward getting it working inside the script executor.  I'm not too concerned because I call the same module to run against all of our PR's.

Thanks again for your help!

[Chad Wilson]

I believe that particular linting rule is effectively mandatory with shellcheck - it can't work against a file which doesn't have a shebang as it doesn't know what rules to apply (POSIX vs bash vs zsh etc semantics).

I would check the target set of scripts/directory you are checking when running inside vs outside GoCD. Getting that message from shellcheck implies it is checking an individual script at the time it gives the error. Can you verify which script it is raising the problem with, i.e include the whole error message, possibly redacting parts of the path that are sensitive? It should tell you in the output, and if the script name is one that's not from your material and is from GoCD or its plugins, it should be reasonably obvious.

I think I was possibly accidentally a bit misleading earlier. The script executor plugin does write a temporary script into the working directory for your build using an auto-generated name (bash -c "./UUID.sh" where UUID.sh contains the contents of your script, with some minor cleanup). If you are asking shellcheck to scan for "all scripts" in the current/working directory, then it is possible it will try and check the temporary script written by the plugin. If that is happening, you probably don't want to do that - I imagine you want to check script contents from source control only. You could do that by cloning into a sub-folder (override checkout directory) and then asking shellcheck to check that folder rather than the entire working directory, or by configuring shellcheck to ignore the script executor generated script.

In any case, if you take the "custom command" route, there is no temporary script written into the working directory, so you shouldn't be able to replicate exactly the same original problem.

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/22a699c1-c3a0-4219-9cc4-c7be600504ddn%40googlegroups.com.