How to use scripts and arguments?

[janosimas]

I was doing some tests and I got some results that I believe can be improved.

When a script is used, the script is copied (?) to a temp file and the temp file is executed.

The execution doesn't seam to respect the cwd nor the args attributes.

[sagiegurari]

when you do 'pwd' at first line of your script, what do you see?
what do you mean by args?
can you provide an example of what you are doing?

[sagiegurari]

@janosimas can you please respond?

[janosimas]

I did some tests to give more information, here is what I would like to do:

[tasks.run_file]
description = "Some script"
cwd = "script_folder/"
script = { file = "my_script.sh" }
args = [
	"arg1"
]

---

What I want:
1 - The script to be executed in cwd
2 - arg1 to be used as an argument of the script

What is happening:

• pwd is returning the folder defined in cwd as expected.
• I found that the script uses $BASH_SOURCE to find the directory of the script. It uses the information to find other source files.

Why do you create a temp script when using script = { file = "..." } ?

[sagiegurari]

so, if it is invoked in the right directory, i'm not 100% sure what the issue you are facing exactly.
can you expand a bit on what is not working?

Why do you create a temp script when using script = { file = "..." } ?

The original implementation had script content embedded inside the makefile.
only later i added external file support.
to keep things simple, i just loaded the content and called the original flow (which uses another crate run_script - https://github.com/sagiegurari/run_script)
the script is not the same as what you write, as i add some stuff there.
for example to fail in case of any error.

[janosimas]

Just to clarify, I already have a script that I cannot modify and I'd like to use it.

This script tries to identify where it is located, using $BASH_SOURCE. This returns the temp directory because you're loading the content and executing in a temporary file in a different folder.

Would it be possible to, instead of loading the content, create a generic script with your boilerplate code that calls the original script without modifying it?

[sagiegurari]

I prefer not to since i moved the entire code to a separate crate and it would require me to duplicate the logic.
why can't you do:

[tasks.run_file]
description = "Some script"
cwd = "script_folder/"
script = '''
. ./myscript.sh
'''
args = [
	"arg1"
]

for this specific script?

basically instead of:
script = { file = "my_script.sh" }
do:
script = ". ./myscript.sh"

[janosimas]

Sorry for the time taken.

I understand the limitation and the particularities of bash and the script I have to use.

I'm using script = "./myscript.sh" but it doesn't work for some of my cases because $BASH_SOURCE points to the temp folder.

---

• edit + update

Defining the execution shell as #!/bin/bash solves the issue

script = '''
#!/bin/bash
./myscript.sh
'''

[janosimas]

On the args subject, it doesn't seam to work correctly with scripts.

Here is an example:

[tasks.demo]
script = "echo $1"
args = [
    "some_arg"
]

This will not print some_arg.

External args work as expected, e.g. makers demo print_this.

The behavior for commands is great and accepts both inputs:

[tasks.demo2]
command = "echo"
args = [
    "some arg",
    "other arg",
    "${@}"
]

[sagiegurari]

that is not how it works.
args are for command, not scripts. why put args for scripts if you can embed them in the script? whats the use case?

args for scripts are the cli args you gave cargo-make, and those are sent to the scripts.

see more at:
https://github.com/sagiegurari/cargo-make#script

[janosimas]

I expected it to work the same way, the use case is simply consistency.

If args is not compatible with scripts, let em suggest to have a warning of incompatible options.

[sagiegurari]

i'm asking because why would you do

script = '''echo $1'''
args = ['test']

and not directly

script = '''echo test'''

whats the use case for that (apart of consistency)?
for commands there is no other way.

Currently, the only failure i give is if 2 actions were defined (for example both command and script or run_task) and warnings in case of unknown attributes (happens if you do spelling mistake for example and write comand instead of command), or using deprecated attributes/tasks.
I could add it, isn't an issue unless you want to PR that

[janosimas]

For me, the consistency is relevant specially when you're maintaining a makefile.

When you have a script that works like a command, args are more explicit.

[task.test_feature]
script = ".\custom_test_script.sh"
args = [
    "--features=some_default_feature",
    "$@", // selection of tests
    "--",
    "--custom-flag"
]

I'll take a look at the code but I'm not sure when I would be able to make a PR.