Hi! So the behavior of this command is intentional. It's intended to emulate the behavior of a Linux utility where you can take the output of this command (a tar archive) and redirect it to an arbitrary file. Since tar is a fairly ubiquitous tool and untarring an archive is trivial it's left to the user to decide how they wish to unpack the bundle. You can check out something like docker export <container> which has similar behavior.

coder templates pull <name> . will not work because it assumes that the destination you are providing is going to be a file that it writes to. So if you want it to work you should be able to do coder templates pull <name> ./foo.tar.

I have noticed that you're on Windows, is it difficult to use this command in its current state for you? I have little experience on Windows but my understanding is that it's common to drop into WSL when doing command line work.

WSL isn't available on all versions of Windows.

I understand wanting to align to a standard, but also tar is a command that is notorious for being hard to work with.

I think a decent compromise would be to have two commands. I'm thinking pull does an unpacking and export gives you the tarball.

@kylecarbs what do you think?

I'd rather have the tar be default behavior, but I think export is a better name.

What do you think about a --extract flag? We could default to cURL behavior, where if the output is a TTY we require explicit - as the argument.

I think an --extract flag is reasonable, we can also certainly support the case where if you specify a directory we will pick a name and write it to the directory as opposed to returning an error.

Well yeah, that's why you implemented it! But pull sounds more like git than a strict downloader. I'm trying to imagine use cases, and I think it's far more likely that someone wants the expanded form. What is their intention when they pull? It's almost always going to reading or editing. Sometimes it's going to be about transporting it somewhere else, but ow we're talking about situations where it's also not in revision control or they can't just do a recursive copy. As the default behavior it just doesn't match how people are typically going to use it.

I spent a few hours fiddling with templates yesterday, and I'm absolutely 100% convinced that pull should extract a directory tree. The intermediate archive file was only ever an impediment.

I definitely think the wording was confusing, I thought it would be like git pull indeed.
Maybe make pull extract and download download a tar or something like that ?

We could export as a directory if stdout is detected as a TTY.

We could export as a directory if stdout is detected as a TTY.

sounds good to me, but then in coder pull <name> <path>, should path be a dir or a tarfile ?

We could export as a directory if stdout is detected as a TTY.

sounds good to me, but then in coder pull <name> <path>, should path be a dir or a tarfile ?

This gets me thinking. We could copy the UX of tar for something intuitive:

Always require a <path>, so the full invocation becomes coder templates pull <template> <path>

• If $path is -, send as tar (current behavior)
• If $path is ., use current working directory
• Else, use $path literally

This looks good to me, except you can't pipe tars in windows (it doesn't work), so maybe add a case where if $path ends with .tar write it as a tar file.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.