[go-nuts] Re: Import files with extensions .xls and .xlsx .

[Tamás Gulácsi]

Yes, with github.com/extrame/xls and github.com/xuri/excelize/v2 .

aadityasha...@gmail.com a következőt írta (2023. február 8., szerda, 
7:29:22 UTC+1):

> Is it possible to import files with extensions .xls and .xlsx with go ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9ea5ae02-9a39-4967-8bb3-5fdde5a23b23n%40googlegroups.com.

[go-nuts] Import files with extensions .xls and .xlsx .

[Aadi Sharma]

Is it possible to import files with extensions .xls and .xlsx with go ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/62ffc4a9-2d48-49d2-8647-f057c1a1d064n%40googlegroups.com.

Re: [go-nuts] recommendations please: go source level debugger for linux

[Jason E. Aten]

https://github.com/glycerine/vprint  shows you how to get 
source file and line numbers (and timestamps) automatically 
in your PMD print statements. 

For examples, I use vv() or VV() for unconditional prints, and pp() or PP() 
for condition prints that only print if Verbose is true.  Debuggers are 
100x slower; combining vprint's approach with debug.Stack() calls and an 
editor that understands stack traces (e.g. emacs)... makes for rapid 
debugging.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4ef26c98-22bf-413f-98c5-66f295199eaan%40googlegroups.com.

[go-nuts] Re: golang protobuf, struct copy problem

[Jason E. Aten]

I wrote greenpack to avoid exactly this; having to maintain two structs in 
sync. Now I just maintain a single Go struct, and the .go source file 
serves as the IDL.  Running go generate updates the generated serialization 
code.

https://github.com/glycerine/greenpack

It is also faster than protobufs, or at least it was 8 years ago when I 
benchmarked it; of course data content will affect benchmarks and upgrades 
to protobufs since then have surely been made.

https://github.com/glycerine/go_serialization_benchmarks

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5466cdfc-f0ce-4423-aece-16c4b6e1bb6dn%40googlegroups.com.

Re: [go-nuts] Re: TCP hand off?

[Jason E. Aten]

Hmm The mysql workbench is going to expect to run the mysql
authentication handshake... so you would have to jump in the middle of the
tcp stream and substitute the actual password, no?   See here for how a new
forward tunnel can be run from a client

https://github.com/glycerine/sshego/blob/05503dd206cf9022d58b7c6ea04e112e65f40659/sshutil.go#L392

and then also instead of the simple io.Copy at

https://github.com/glycerine/sshego/blob/05503dd206cf9022d58b7c6ea04e112e65f40659/shovel.go#L66

you could filter for the credentials and substitute the actual correct one
for the user.

This would be client side though, so users could use strings on the binary
to find the actual passwords. But you could also intercept the tcp pump on
the server side I think; here:

https://github.com/glycerine/sshego/blob/05503dd206cf9022d58b7c6ea04e112e65f40659/direct.go#L73

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPNEFAb4fwZciCRytgUzm4gFcBQ33u_0dmVf2bHYAPHyBSW5wA%40mail.gmail.com.

[go-nuts] Re: Drain channel on demand without busy looping?

[Jason E. Aten]

I have the requirement of make sure that downstream processes all data 
currently being sent. 

I usually have the client submit a Request struct the includes a new Done 
channel. When the downstream goroutine
finishes processing a given Request r, they close the r.Done channel. The 
client can wait or select on the r.Done channel to
know when processing is finished.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/201a1bc5-6f99-4ec5-a19a-40943e7d7c76n%40googlegroups.com.

[go-nuts] Re: TCP hand off?

[Jason E. Aten]

I don't recall (would have to re-read the SSH RFCs) if an ssh server is 
allowed to initiate a tunnel. It might have to be started on the client 
side. But that is pretty easy to arrange using the ssh -L flag.

Could you have them run your authentication tool after they ssh login with 
ssh -L 3306:127.0.0.1:3307  user@databasehost, so the workbench tunnel is 
already started... and have the authentication tool forward 3307 to 3306 
only if authentication succeeds?  Hmm they still wouldn't have logged 
in yet though... or would they?  It's hard to say without understanding the 
details of your authentication tool.

That would be (less code) simple approach...if it works.  If you want to 
get complicated, I have an ssh library for that which may be helpful.

https://github.com/glycerine/sshego

It lets you write custom ssh servers, clients, etc.

On Tuesday, February 7, 2023 at 2:54:26 PM UTC-6 Rich wrote:

> I have a database that I want to be able to allow users to connect to. I 
> didn't design this database, just trying to come up with a way to allow 
> users to connect.  The way they set this database up is that there are 
> three users, Read, Read/write, and Admin.  What I have done is write a tool 
> that can authenticate a specific user such as jsmith234, he's a member of 
> the Admin team, when using my cli tool it logs jsmith in using the admin 
> user of the database. JDoe432 is a member of the read group, only gets read 
> access, when they run the tool, the tool logs the user in with read-only 
> access.
>
> Users can query the database, get into a mysql shell, dump the database, 
> restore the database, save tables as excel, or csv -- but only from the 
> command line. What my users want to do is be able to use tools like mysql 
> workbench.  I don't want to give them the database passwords as then you're 
> constantly getting emails with people asking for the right creds, then 
> you've got to look them up, give them the right user which is a pain.  I 
> don't want to get into what happens when we reset the password which by 
> corporate standards is every 90 days. Currently I only have to change it in 
> the database and in my tool. 
>
> My question is if there is a way to write a middleware app that can be 
> run, so that the user logs in with SSH, the tool authenticates them, and 
> then starts a port forward back to their system allowing mysql workbench to 
> connect. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3edb4559-1625-4832-87af-b677f0af8d56n%40googlegroups.com.

Re: [go-nuts] Error Handling

[Richard Masci]

You said: "and FTR, I'd also consider your function a bad idea, but that's
none of my business" <- I'll be the first to say not all my ideas are good
ones, maybe this one isn't? Thanks for your response.


On Tue, Feb 7, 2023 at 4:45 PM Axel Wagner 
wrote:

> No, that is not possible. Only a `return` statement can return.
> You *can* unwind the stack, using `panic` or `runtime.GoExit` (which is
> what `t.Fatal` does) but it's a bad idea in general (and FTR, I'd also
> consider your function a bad idea, but that's none of my business).
>
> On Tue, Feb 7, 2023 at 10:39 PM Rich  wrote:
>
>> In most of my code I create a function to handle errors. looks something
>> like this:
>>
>> func errorHandle(err error, str string, ex bool) {
>>  if err != nil {
>>   fmt.Printf("error: %s -- %v\n",str, err)
>>  }
>>  if ex {
>> os.Exit(1)
>>  }
>> }
>>
>> This cleans up my code:
>> inFile, err := os.ReadFile("Mydata.txt")
>> errorHandle(err,"read mydata.txt",true) // The true will exit
>>
>> So you see that I can exit the program when there is an error, what I
>> want to know is if it's possible to do the same thing inside a function, to
>> where I don't exit the program but return from the function:
>>
>> func OpenFile( filename string) []byte {
>> inFile,err := os.ReadFile(filename)
>> errReturn(err, "read "+filname,true)
>>
>> When there is an error it would return from the OpenFile function,
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJ0CmuGaHPF9ZZpHZf2G8N7eY_NM8%3DpE9z6vGp8tYvEnv6vbnQ%40mail.gmail.com.

Re: [go-nuts] Error Handling

['Axel Wagner' via golang-nuts]

No, that is not possible. Only a `return` statement can return.
You *can* unwind the stack, using `panic` or `runtime.GoExit` (which is
what `t.Fatal` does) but it's a bad idea in general (and FTR, I'd also
consider your function a bad idea, but that's none of my business).

On Tue, Feb 7, 2023 at 10:39 PM Rich  wrote:

> In most of my code I create a function to handle errors. looks something
> like this:
>
> func errorHandle(err error, str string, ex bool) {
>  if err != nil {
>   fmt.Printf("error: %s -- %v\n",str, err)
>  }
>  if ex {
> os.Exit(1)
>  }
> }
>
> This cleans up my code:
> inFile, err := os.ReadFile("Mydata.txt")
> errorHandle(err,"read mydata.txt",true) // The true will exit
>
> So you see that I can exit the program when there is an error, what I want
> to know is if it's possible to do the same thing inside a function, to
> where I don't exit the program but return from the function:
>
> func OpenFile( filename string) []byte {
> inFile,err := os.ReadFile(filename)
> errReturn(err, "read "+filname,true)
>
> When there is an error it would return from the OpenFile function,
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHgrMYVNCzbTtf5%3De8qDwyarbH44GvdXieFSKq502ChtQ%40mail.gmail.com.

[go-nuts] Error Handling

[Rich]

In most of my code I create a function to handle errors. looks something 
like this:

func errorHandle(err error, str string, ex bool) {
 if err != nil {
  fmt.Printf("error: %s -- %v\n",str, err)
 }
 if ex {
os.Exit(1)
 }
}

This cleans up my code:
inFile, err := os.ReadFile("Mydata.txt")
errorHandle(err,"read mydata.txt",true) // The true will exit

So you see that I can exit the program when there is an error, what I want 
to know is if it's possible to do the same thing inside a function, to 
where I don't exit the program but return from the function:

func OpenFile( filename string) []byte {
inFile,err := os.ReadFile(filename)
errReturn(err, "read "+filname,true)

When there is an error it would return from the OpenFile function,

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com.

[go-nuts] TCP hand off?

[Rich]

I have a database that I want to be able to allow users to connect to. I 
didn't design this database, just trying to come up with a way to allow 
users to connect.  The way they set this database up is that there are 
three users, Read, Read/write, and Admin.  What I have done is write a tool 
that can authenticate a specific user such as jsmith234, he's a member of 
the Admin team, when using my cli tool it logs jsmith in using the admin 
user of the database. JDoe432 is a member of the read group, only gets read 
access, when they run the tool, the tool logs the user in with read-only 
access.

Users can query the database, get into a mysql shell, dump the database, 
restore the database, save tables as excel, or csv -- but only from the 
command line. What my users want to do is be able to use tools like mysql 
workbench.  I don't want to give them the database passwords as then you're 
constantly getting emails with people asking for the right creds, then 
you've got to look them up, give them the right user which is a pain.  I 
don't want to get into what happens when we reset the password which by 
corporate standards is every 90 days. Currently I only have to change it in 
the database and in my tool. 

My question is if there is a way to write a middleware app that can be run, 
so that the user logs in with SSH, the tool authenticates them, and then 
starts a port forward back to their system allowing mysql workbench to 
connect. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4f0c20c2-b866-495e-a78b-b03977a556b7n%40googlegroups.com.

Re: [go-nuts] How to correctly use exec.Command and properly clean up all pipes

[Rich]

Not sure if this helps at all, but I've stopped using Go's exec and use 
bitfield's script command. You can do so much more with it than you can 
with the standard exec and it's shorter to implement than Go's exec.

https://github.com/bitfield/script


On Monday, February 6, 2023 at 5:43:45 PM UTC-5 lchri...@twilio.com wrote:

> Filed under https://github.com/golang/go/issues/58369.
>
> --
> Lucas Christian   
> Staff Software Engineer, Voice and SIP Connectivity
> On Fri, Feb 3, 2023 at 2:14 PM Ian Lance Taylor  wrote:
>
>> On Fri, Feb 3, 2023 at 1:48 PM Lucas Christian  
>> wrote:
>> >
>> > Thanks for the reply and confirmation—theoretical but we have had 
>> systems fail this way before (including the system this codebase will 
>> eventually be deployed on). Of course practically once that happens, the go 
>> process leaking one more file descriptor is probably the least of our 
>> worries.
>> >
>> > For completeness is there an issue tracker it would be worth filing 
>> this off to?
>>
>>
>> https://urldefense.com/v3/__https://go.dev/issue__;!!NCc8flgU!aclVyNiB3jXq50nLgI3WT74VmhVQaslq5Q_idqxqQ3QGe2HY-8Bx2A1dkZvNyGTYBD6wvTQF3tG0ng$
>>   
>> (which redirects to GitHub).
>
>
>>
>> Ian
>>
>>
>> > Lucas Christian
>> > Staff Software Engineer, Voice and SIP Connectivity
>> > On Fri, Feb 3, 2023 at 12:44 PM Ian Lance Taylor  
>> wrote:
>> >>
>> >> On Fri, Feb 3, 2023 at 12:38 PM 'Lucas Christian' via golang-nuts
>> >>  wrote:
>> >> >
>> >> > Apologies for reviving an old thread, but thought this might be the 
>> most efficient way to keep context.
>> >> >
>> >> > I'm looking at a similar issue Thomas encountered, but in this case 
>> I'm concerned about how to handle errors returned from 
>> StdoutPipe()/StderrPipe() and properly clean up after that. e.g.:
>> >> >
>> >> > cmd := exec.Command(myCommand, myArgs...)
>> >> >
>> >> > stdout, err := cmd.StdoutPipe()
>> >> > if err != nil {
>> >> > // log warning or bail out
>> >> > }
>> >> >
>> >> > stderr, err := cmd.StderrPipe()
>> >> > if err != nil {
>> >> > // log warning, if we bail out we will leak the os.Pipe 
>> allocated internally in cmd.StdoutPipe()
>> >> > }
>> >> >
>> >> > err = cmd.Start() // if this fails, it *will* clean up both pipes
>> >> >
>> >> > Looking at the source, both StdoutPipe() and StderrPipe() allocate 
>> os.Pipe()s internally. Since these methods return the reader I can 
>> technically close that one myself but the writer side of the pipe will 
>> presumably leak if cmd.Start() is never called. In my usecase it's probably 
>> an acceptable compromise to just complain to the log and move along with 
>> starting the process, but if my understanding is correct it feels like an 
>> omission in the language spec that there is seemingly no way to clean up a 
>> the pipes associated with a command that is never started.
>> >>
>> >> As a practical matter I wouldn't worry about it, as StdoutPipe and
>> >> StderrPipe should approximately never fail.  I think that the only way
>> >> they could fail would be if you hit the limit on the total number of
>> >> open file descriptors.
>> >>
>> >> If they do manage to fail, it's a fair point that there is no
>> >> supported way to close any earlier pipes.  Again it's unlikely to be a
>> >> practical problem as any lingering file descriptors will get closed by
>> >> the finalizer associated with each file descriptor.  But, yes, it
>> >> looks like a bit of a hole in the API.
>> >>
>> >> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/14152923-9531-430a-8108-0f40102106a4n%40googlegroups.com.

[go-nuts] Re: how to get the json line number when getting unmarshal errors?

[Rich]

I use a tool called hjson 
hjson/hjson-go: Hjson for Go (github.com) 

This not only lets you put comments into the code but many times can be 
used to fix json. Some of my tools the user has to generate a JSON payload 
then send it with my tool. I will take their json and run it through hjson 
first. It doesn't catch everything, but it has fixed quite a few json files 
that had little things like a missing comma. 

On Monday, February 6, 2023 at 6:22:29 PM UTC-5 dave wrote:

> I'm getting the error  
>
> panic: json: cannot unmarshal string into Go value of type 
> map[string]*json.RawMessage but it does not tell me which line or section 
> of my json is causing the issue. How can I see this?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1366d8f7-a9d0-4c78-996f-9dae73e240abn%40googlegroups.com.

[go-nuts] Re: Re-entrant locks?

[jake...@gmail.com]

Or maybe its because, if the language included them, then people would use 
them. And that is (almost?) always a bad idea. Not providing a tool that 
usually leads to code that is hard to maintain, and often incorrect or 
poorly designed seems to be in line with Go's overall vision. One of the 
reasons  I really like using go is that it allows mediocre programmers to 
write descent, reasonably solid code. And when working on a team it really 
matters, because, lets face it, mediocre developers abound. 

Ian weighed in on reentrant locks back in the early days: 
https://groups.google.com/g/golang-nuts/c/4sx5pPp8gFw/m/afBJTrc7UWIJ. There 
are also many articles on why reentrant locks are evil. Obviously, there 
are those that disagree. 
On Tuesday, February 7, 2023 at 8:41:19 AM UTC-5 ren...@ix.netcom.com wrote:

> I know this topic comes up a bit and I’ve done a bit more research. 
>
> Is a contributing reason that Go does not have re-entrant locks is that Go 
> does not have any way to get Go routine identity? It seems you cannot write 
> a reentrant lock - at least not with the typical syntax - without 
> specialized runtime support. 
>
> The only public way I can think of is something like
>
> somelock.Lock(ctx)
>
> But then you need to make every method accept a context.Context instance. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2db39671-485c-4ee1-ab49-28de41969510n%40googlegroups.com.

Re: [go-nuts] extract VCS branch name used during build

[Tobias Klausmann]

Hi! 

On Mon, 06 Feb 2023, quin...@gmail.com wrote:
> I would like to be able to extract the VCS branch name used during build.
> Currently I append "-X main.BranchName=${BRANCH}" to the build line which 
> works, but I was hoping there might be a cunning way to extract this from 
> runtime/debug?

Indeed there is. On top of the already mentioned approaches using go
generate, the runtime/debug package:

```
import "runtime/debug"

var Commit = func() string {
if info, ok := debug.ReadBuildInfo(); ok {
for _, setting := range info.Settings {
if setting.Key == "vcs.revision" {
return setting.Value
}
}
}
return ""
}()
```

(shamelessly stolen from
https://icinga.com/blog/2022/05/25/embedding-git-commit-information-in-go-binaries/)

HTH,
Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/Y%2BJ%2BHEXQCJy70QkU%40skade.schwarzvogel.de.

[go-nuts] Re: Re-entrant locks?

[Robert Engels]

And you have to make sure that a ctx is not incorrectly shared… ugh. 

> On Feb 7, 2023, at 7:41 AM, Robert Engels  wrote:
> 
> I know this topic comes up a bit and I’ve done a bit more research. 
> 
> Is a contributing reason that Go does not have re-entrant locks is that Go 
> does not have any way to get Go routine identity? It seems you cannot write a 
> reentrant lock - at least not with the typical syntax - without specialized 
> runtime support. 
> 
> The only public way I can think of is something like
> 
> somelock.Lock(ctx)
> 
> But then you need to make every method accept a context.Context instance.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D4211DBD-3147-41E0-B679-C0569DC2029B%40ix.netcom.com.

[go-nuts] Re-entrant locks?

[Robert Engels]

I know this topic comes up a bit and I’ve done a bit more research. 

Is a contributing reason that Go does not have re-entrant locks is that Go does 
not have any way to get Go routine identity? It seems you cannot write a 
reentrant lock - at least not with the typical syntax - without specialized 
runtime support. 

The only public way I can think of is something like

somelock.Lock(ctx)

But then you need to make every method accept a context.Context instance. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/69B98553-62B3-44BC-B3D9-B0001214139C%40ix.netcom.com.