Read Taskfile from stdin

[dAnjou]

Hi, it'd be cool to do something like this:

generate_taskfile.sh | task --taskfile - lorem

[mgbowman]

I also tried with file pipe redirection 😞

task -t <(cat ~/shared/Taskfile.yaml)
task: No Taskfile found in "/dev/fd/12". Use "task --init" to create a new one

I'm interested in this for a remote rtask shell alias...

alias rtask='task -t <(curl ...)'
alias rtask='curl ... | task -t -'

[ghostsquad]

bump. This is needed. I'm dynamically generating taskfiles, and it would be nice if I didn't have to write it to disk first.

[brianbraunstein]

It would be nice if this worked:

task -t <(jsonnet foo.jsonnet)

and/or something like this:

export TASK_TASKFILE_PREPROCESSOR=jsonnet
export TASK_TASKFILE_NAME=foo.jsonnet
task

[pd93]

This was pretty low-hanging fruit now that we have the Node interface. See #1483. Feedback very welcome if you have the time to test before it is merged.

[brianbraunstein]

Thanks for looking into it.

I'm coming into this code cold, but I see here:

• task/taskfile/node_file.go

  Lines 48 to 53 in 247c258

  	f, err := os.Open(node.Location())
  	if err != nil {
  	return nil, err
  	}
  	defer f.Close()
  	return io.ReadAll(f)

The read is done with os.Open() and io.ReadAll(), which I would think should work with a device file, but here:

• task/taskfile/taskfile.go

  Line 38 in 9ee0ea6

  if fi.Mode().IsRegular() {

  
  there's a check to IsRegular() which prevents this from working

task -t <(jsonnet foo.jsonnet)
jsonnet foo.jsonet | task -t /dev/stdin

It might be that a 1 line change there at the IsRegular() check could do the trick, to just be more permissive than only "regular" files, and instead permit any file that's compatible with os.Open() and io.ReadAll()

[brianbraunstein]

Also, it would be nice to be able to stay do something like -t - to explicitly ask for stdin, and then internally use os.Stdin. However, the following then stands out to me as potentially problematic.

• task/cmd/task/task.go

  Lines 206 to 208 in 9ee0ea6

  	if flags.dir != "" && flags.entrypoint != "" {
  	return errors.New("task: You can't set both --dir and --taskfile")
  	}

  
  Is it necessary to disallow -d and -t ? It seems like if you're doing-t <(foo) or -t /dev/stdin that you may want to change the directory too, but I guess you can always just (cd somewhere; task -t <(foo)

[pd93]

It might be that a 1 line change there at the IsRegular() check could do the trick, to just be more permissive than only "regular" files, and instead permit any file that's compatible with os.Open() and io.ReadAll()

@brianbraunstein I think we only really want to add ModeDevice to the list? I would like this check to be as restrictive as possible unless we have a specific reason to allow more modes. (Full list of modes here). Please feel free to suggest other modes you think are necessary and why.

Is it necessary to disallow -d and -t ? It seems like if you're doing-t <(foo) or -t /dev/stdin that you may want to change the directory too, but I guess you can always just (cd somewhere; task -t <(foo)

It is not necessary no. However, there is a surprising amount of internal work required in order to do this in a way that is both backwards compatible and maintains the expected behaviour. This functionality is also required for #1347 to work correctly and as such, I have been working on it over there instead of here.

[brianbraunstein]

@pd93

Please feel free to suggest other modes you think are necessary and why.

I think ModeNamedPipe and ModeSymlink would be important too, see this:

$ file <(echo hi)
/dev/fd/63: symbolic link to pipe:[1593078]
$ ll <(echo hi)
lr-x------ 1 brian brian 64 Feb 19 23:56 /dev/fd/63 -> 'pipe:[1593104]'

$ uname -a
Linux bbt14 5.15.0-72-generic #79-Ubuntu SMP Wed Apr 19 08:22:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

...there is a surprising amount of internal work required...

when I was digging through the code I remember noticing it's passing around file names and/or directory names rather than just the file descriptor (or IO object wrapping it), so I believe you that there are some challenges caused by this. I could definitely live with the (cd somewhere; task -t <(foo) workaround for now.