Re: [go-nuts] Running commands via SSH
kburke...@gmail.com wrote:
> Hi, I'd like to SSH to a remote host and run an arbitrary command. I found
> this pretty difficult to do with existing Go libraries.
>
> The first problem I had was around escaping; commands run locally are
> appropriately escaped but I found it difficult to get the right escaping
> for commands run remotely. As an example, this hangs, I believe because of
> the {<& in the middle of the command.
>
> cmd := exec.Command("ssh", "remote-host", "echo", "zdUZUKv{<&MsZG")
> bits, err := cmd.CombinedOutput()
> if err != nil {
> log.Fatal(err)
> }
> os.Stdout.Write(bits)
>
> Note exec.Command("echo", "{<&") runs just fine.
>
(my previous post didn't seem to make it. this is probably better anyway.)
I think ssh is using your login shell execute the remote command so the
<& is being interpreted as a redirect whereas when you run echo on
your local machine, it is simply being fork()/exec()ed and your
string is passed directly as a parameter without being interpreted
by a shell.
When I try your ssh command my shell (bash) gives the following
complaint:
err: exit status 1
bash: MsZG: ambiguous redirect
I can get it to work by escaping the '<' and '&' individually as well as
putting the entire offending argument in single quotes.
Which characters are special depends on your shell and even which mode
your shell is running in! This is trickier than it seems at first glance
and I think the ultimate solution is that you'll have to be aware of
which shell you're running on the remote machine and how to properly
escape arguments for it.
It'd be interesting to know if there is a way to get ssh to execute a
command without invoking the login shell. After a quick glance of the
man page and source (for FreeBSD at least) I couldn't find a way.
-ayan
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Deleting the /r/golang subreddit
I don't use the site, nor understand how any immediate conflicts of interest can manifest based on the CEO's actions that justify removing the subreddit or locking it down. Why not add a community to the official golang.org site and let the subreddit die of natural causes? It would be a favorable outcome if Reddit ever disappeared in the future to the hand of some other site: no content would need to be moved and the language's community posts would be self-contained. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] CFG for a Go program
You can get the CFG (control flow graph) for a function by setting the environment variable GOSSAFUNC to the function in question when building. It will generate a file named ssa.html in the current directory which you can load into a browser. It doesn't draw the CFG explicitly but the nodes (basic blocks) and edges are all listed. GOSSAFUNC=foo go build will generate an ssa.html file for the foo function (as well as spew lots of info about foo to stdout). On Saturday, November 26, 2016 at 4:05:03 AM UTC-8, Michael Jones wrote: > > I had the same reaction. More of a riddle than a question. > > If CFG means Context Free Grammar, then how could it be something of a > program rather than of the language? > > if CFG means Configuration File, then the programming language would have > nothing to do with the quest for the file, which would be a separate entity. > > If CFG means Control Flow Graph, then "access" is problematic as the flow > graph is more an attribute to be derived rather than a manifest element to > be accessed. > > Other CFGs, including Certificat de Formation Générale, the airport code > for Cienfuegos Cuba, Cubic Feet Gas, Cross Florida Greenway, and the > airline Condor Flugdienst GmbH, amongst others, seem far removed from Go > programs. > > So, the best guest is Control Flow Graph. The best answer is to start with > the graphical output of execution profiling as explained in the Go Blog (in > 2011): > > https://blog.golang.org/profiling-go-programs > > On Sat, Nov 26, 2016 at 6:45 AM, Tamás Gulácsi > wrote: > >> What the hell is a CFG? >> >> -- >> 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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Michael T. Jones > michae...@gmail.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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question about flow of context
Conventionally context is passed as the first argument to function and method calls. I'm not sure what you mean by "inner facet" there. On 25 Nov 2016 16:58, "Diego Bernardes" wrote: > Got one question about the design of some packages using the new 'context' > in golang. Let's assume we have a webserver, when some request get in, we > can get the context from request, and this request can trigger several > packages. > What is the best way to send this context to the other packages? Pass a > reference to it? Or pass a inner facet with something like 'WithValue'? > > I need to permeate the context to all the functions a web request can > trigger inside the application, this is used to generate logs, metrics, > errors, etc... > > What is the best aproach to solve this issue? > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Go Routines use continuations to allow yelding?
On Sat, Nov 26, 2016 at 8:32 PM Olivier El Mekki wrote: > Am i correct to assume from previous messages that if I use MAX_PROCS=1 and don't use channels, my functions will run from start to end in the order they've been piled up using the `go` keyword? No, sorry, the language specification does not say the scheduler provides any such guarantee. -- -j -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Error Handling
Just for clarification, the function fn() must return an interface for this to work. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Go Routines use continuations to allow yelding?
Am i correct to assume from previous messages that if I use MAX_PROCS=1 and don't use channels, my functions will run from start to end in the order they've been piled up using the `go` keyword? This could yield interesting properties, because this means that even using channels, maybe we could write concurrent code and still have a chance to have predictable and reproducible execution in testing environment. On Friday, November 25, 2016 at 10:51:41 PM UTC+1, Dave Cheney wrote: > > > > On Saturday, 26 November 2016 08:00:24 UTC+11, Roger Alsing wrote: >> >> So it works very similar to normal OS thread context switching, but more >> explicit? >> > > Yes, goroutine switching occurs a known points; effectively where the > goroutine is blocked from proceeding; sending and receiving on channels (if > they are full/empty respectively), trying to acquire a locked mutex, and > performing IO. These operations happen frequently in a program that > interacts with others so things more or less work out. > > >> The code will push all local state to the go routine stack, pop the state >> for the next go routine and change the stack pointer? >> > > The cute thing is the Go function call convention is caller save, so when > a goroutine enters the scheduler there is no state to be saved, it's > already saved on the stack by the normal function call convention. As Ian > said above the scheduler just finds the SP and PC for a new goroutine and > swaps them for the current one. The new goroutine awakes at the bottom of > the scheduler, and returns to its original control flow. > > >> >> And this is cheaper than context switching as threads have their own 1 or >> 4 mb stack allocated while go routines have a linked list for its stack >> (afaik?) ? >> > > Goroutines used to have a linked list of stack segments, we dropped that > in Go 1.3 (might have been 1.2, i'd have to check), now stack segments grow > and shrink with a cheap check in the preamble of the function; if there > isn't enough stack to perform the function (this is known precisely at > compile time), then the function traps into a slow path that doubles the > stack allocation by copying the whole stack to a new area, then restarts > the function. Stack shrinking is handled via the GC cycle when a goroutine > has a large amount of unused stack. > > >> is that the major difference? >> > > I think so, it makes goroutines cheap to create; only a few kb of initial > stack, cheap to use; no trip through kernel space to save a lot of state, > and trash TLB's and caches, and cheap to have many of them; in operation > hundreds of thousands of goroutines in a busy server are the norm. This is > also pretty much the case against threads. > > Here is a presentation I gave at OSCON last year about all these things, > https://dave.cheney.net/2015/08/08/performance-without-the-event-loop > > >> >> >> Den fredag 25 november 2016 kl. 17:34:24 UTC+1 skrev Ian Lance Taylor: >>> >>> On Fri, Nov 25, 2016 at 2:18 AM, wrote: >>> > I have seen a lot of confusion on how go routines actually work >>> internally. >>> > Will the function execution ontop of the go routine be rewritten to a >>> statemachine with continuations in the same way as the C# async await does? >>> >>> I do not know how C# async await works. That said, goroutines are not >>> rewritten to state machines. >>> >>> >>> > If I have only 1 OS thread and 1000 go routines, obviously there must >>> be some sort of "magic" that makes it possible to multiplex these ontop of >>> that thread. >>> > How do the go routines store state so that they can continue from the >>> last execution point when they resume execution? >>> >>> A goroutine is basically a small stack. All the goroutine state is >>> saved on the stack. To switch to a different goroutine, the goroutine >>> scheduler changes the stack pointer. On the new goroutine, it looks >>> like the function call into the scheduler simply returns, and the >>> goroutine continues running. >>> >>> This is a standard programming technique known as a "coroutine". For >>> Go we used the name "goroutine" because 1) it is cute; 2) goroutines >>> have functionality not available in most coroutine libraries, such as >>> multiplexing across many OS threads and automatic use of epoll for >>> network connections. >>> >>> >>> > Is it safe to say that Go gives you the exact same support as the C# >>> (and others) async await while still writing code that looks sequential? >>> >>> I don't know C#. goroutines let you write code that looks sequential >>> because it actually is sequential. >>> >>> 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Running commands via SSH
It works for me (over ssh) when I run this string as the command: `echo
'zdUZUKv{<&MsZG'`
Use backticks for the string literal, then enclose your argument string in
single-quotes.
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Running commands via SSH
Hi, I'd like to SSH to a remote host and run an arbitrary command. I found
this pretty difficult to do with existing Go libraries.
The first problem I had was around escaping; commands run locally are
appropriately escaped but I found it difficult to get the right escaping
for commands run remotely. As an example, this hangs, I believe because of
the {<& in the middle of the command.
cmd := exec.Command("ssh", "remote-host", "echo", "zdUZUKv{<&MsZG")
bits, err := cmd.CombinedOutput()
if err != nil {
log.Fatal(err)
}
os.Stdout.Write(bits)
Note exec.Command("echo", "{<&") runs just fine.
I then wondered if creating a ssh Session (via golang.org/x/crypto/ssh) and
running the command would help. But I wasn't able to get this working that
well; when I run exec.Command("ssh", "remote-host"), the ssh command will
parse my local .ssh/config and pull the appropriate settings from there,
but the Go library doesn't.
- Is there a tool or library for appropriately escaping commands run on a
remote machine? I understand this can lead to security problems and am
worried about getting this wrong
- Is there a tool or library for parsing SSH configs & returning the
appropriate configuration for a host? I found one community library, but
the parser was not implemented very well.
Thanks for your help,
Kevin
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] CFG for a Go program
I had the same reaction. More of a riddle than a question. If CFG means Context Free Grammar, then how could it be something of a program rather than of the language? if CFG means Configuration File, then the programming language would have nothing to do with the quest for the file, which would be a separate entity. If CFG means Control Flow Graph, then "access" is problematic as the flow graph is more an attribute to be derived rather than a manifest element to be accessed. Other CFGs, including Certificat de Formation Générale, the airport code for Cienfuegos Cuba, Cubic Feet Gas, Cross Florida Greenway, and the airline Condor Flugdienst GmbH, amongst others, seem far removed from Go programs. So, the best guest is Control Flow Graph. The best answer is to start with the graphical output of execution profiling as explained in the Go Blog (in 2011): https://blog.golang.org/profiling-go-programs On Sat, Nov 26, 2016 at 6:45 AM, Tamás Gulácsi wrote: > What the hell is a CFG? > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- Michael T. Jones michael.jo...@gmail.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. For more options, visit https://groups.google.com/d/optout.
