murex icon indicating copy to clipboard operation
murex copied to clipboard

More detailed type inference with getfile?

Open tiymat opened this issue 7 months ago • 2 comments

Describe the problem:

Hi all,

Just kicking this idea around, not sure if this should be an issue or discussion. I was using getfile and noticed that when retrieving a .json file, it wrote the content as a str variable, and I had to manually cast it.

I patched getfile.go to report the Content-Type header and its resulting type (adding the first 3 lines below)

	ct := resp.Header.Get("Content-Type")
	dt := lang.MimeToMurex(ct)
	os.Stdout.WriteString(fmt.Sprintf("Header: %s, Data type: %s\n", ct, dt))
	p.Stdout.SetDataType(lang.MimeToMurex(resp.Header.Get("Content-Type")))

and saw that Content-Type was reporting text/plain.

[~] > getfile https://raw.githubusercontent.com/lmorg/murex/refs/heads/master/package.json -> set foo
Header: text/plain; charset=utf-8, Data type: str
Downloaded 614 bytes to package.json
[~] > runtime --variables -> ["foo"] -> ["DataType"]
str 

Possible ways to implement: I was wondering whether it would be reasonable to, when the text encoding is text/plain, fall back to a secondary check of the download filename extension and see if it indicates a likely match to a Murex data type, e.g. .json, .csv, etc., maybe with a GetExtType call like I believe open already uses?

Additional context: Unrelated, but I did find the "Downloaded x bytes to y.z" message a bit confusing at first, given that I was piping the output to a command, and no file was being created on disk in my working directory.

Documentation: Please rate your success with referring to the docs @ https://murex.rocks

  • [ ] I haven't read the docs / the solution should be more discoverable
  • [x] I have read the docs but the content wasn't clear
  • [ ] I have read the docs but this query was missing
  • [ ] I have read the docs and this query was answered but I'm still having problems

tiymat avatar Apr 01 '25 04:04 tiymat