Problem
When using gog gmail attachment <messageId> <attachmentId> --out /tmp/ --name invoice.pdf, the --name flag is silently ignored because --out is set. The tool treats /tmp/ (a directory) as the output file path instead of combining the directory with the filename.
The CLI struct documents this behavior:
Name string `name:"name" help:"Filename (only used when --out is empty)"`
But this is surprising and leads to downstream bugs (see #related issue about caching).
Expected behavior
Either:
- When
--out is a directory, combine it with --name to form the full path (e.g. /tmp/ + invoice.pdf → /tmp/invoice.pdf), or
- Error clearly when
--out is a directory path, telling the user to provide a full file path
Reproduction
gog gmail attachment <messageId> <attachmentId> --out /tmp/ --name invoice.pdf
# Output: path=/tmp/ cached=true bytes=512
# Expected: path=/tmp/invoice.pdf cached=false bytes=<actual size>
The output path=/tmp/ and bytes=512 (the directory metadata size) confirms that /tmp/ itself is being treated as the target file.
Filed by an AI agent on behalf of @schickling
Problem
When using
gog gmail attachment <messageId> <attachmentId> --out /tmp/ --name invoice.pdf, the--nameflag is silently ignored because--outis set. The tool treats/tmp/(a directory) as the output file path instead of combining the directory with the filename.The CLI struct documents this behavior:
But this is surprising and leads to downstream bugs (see #related issue about caching).
Expected behavior
Either:
--outis a directory, combine it with--nameto form the full path (e.g./tmp/+invoice.pdf→/tmp/invoice.pdf), or--outis a directory path, telling the user to provide a full file pathReproduction
The output
path=/tmp/andbytes=512(the directory metadata size) confirms that/tmp/itself is being treated as the target file.Filed by an AI agent on behalf of @schickling