Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testscript: provide fprintf as builtin command #142

Open
myitcv opened this issue Jun 4, 2021 · 2 comments
Open

testscript: provide fprintf as builtin command #142

myitcv opened this issue Jun 4, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@myitcv
Copy link
Collaborator

myitcv commented Jun 4, 2021

txtar archives frequently form the basis of issue reports, which means they get copy/pasted to GitHub issues and the like. This causes tab characters to be converted to spaces (there may be other lossy conversions).

I've just come across a case where I need a file in a txtar archive input to testscript, shared via a GitHub issue, to include tab characters. i.e. the rewrite to space is not acceptable, because the tab characters form the basis of the issue. Very niche and quite possibly a solid edge case, but I'm raising this for discussion to see whether there would be wider benefit to the following approach.

What I'm thinking is that it would be useful to have a fprintf builtin command (someone please save me on the naming front) which takes a number of file names, reads each in turn, interprets the contents of a file as an interpreted string literal, then writes the result back to a file.

This would therefore allow:

fprintf main.go
go run main.go

-- main.go --
package main

func main() {
\tprintln("Hello\\tworld")
}

Thoughts?

@myitcv myitcv added the enhancement New feature or request label Jun 4, 2021
@myitcv myitcv changed the title cmd/testscript: provide fprintf as builtin command testscript: provide fprintf as builtin command Jun 4, 2021
@myitcv
Copy link
Collaborator Author

myitcv commented Jul 29, 2021

This raises the somewhat interesting question of what changes (if any) would be made to txtar-c: how would the user of that command indicate that a particular file (or files) should be written to the resulting txtar as an interpreted string literal? Perhaps, given this workflow would be rare, it would be acceptable to accept a flag which can be repeated, a flag that specifies a glob of files that should be encoded in this way?

@myitcv
Copy link
Collaborator Author

myitcv commented Jul 29, 2021

@rogpeppe has kindly pointed out a flaw in my testing. In that testing, it appeared to me that GitHub did not preserve tabs in code snippets. However, that is not the case, i.e. it does preserve them. What is breaking things in my setup is that xterm's insert-selection writes tabs as spaces. Within Vim, a paste from the clipboard works as expected.

So whilst the GitHub use case is perhaps no longer an issue, I suspect it would probably be a "safe" idea to have something like this feature, in case someone is pasting from somewhere other than GitHub, or their local setup also writes tabs as spaces etc. It helps to remove variables from the equation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant