On Wed, Sep 30, 2020 at 5:17 PM Patrick Smith wrote:
> Not a general solution, but if you are only writing a small amount of
> data, you can simply write it to the pipe and then exec the other program:
> https://play.golang.org/p/e0UQRE6SsT4
>
> If I recall correctly, many years ago you would hav
if the target program is under your control, you can just write to a file,
write the location to that file to the stdin and pick up from the file in the
target...
[Joop Kiefte - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=ph9ch)
[ph9ch]
On October 1, 2020 at 0:16
Not a general solution, but if you are only writing a small amount of data,
you can simply write it to the pipe and then exec the other program:
https://play.golang.org/p/e0UQRE6SsT4
If I recall correctly, many years ago you would have been able to write 256
bytes this way. No doubt someone else c
On Wed, Sep 30, 2020 at 3:33 PM Chris Tierney wrote:
>
> Is there a way to accomplish this in go? Normally what I'd do is `fork` a
> process that would handle writing to a pipe, `dup` the read end of the pipe
> to stdin and then `exec` to the process I want to run, but `syscall` doesn't
> have
I'm ok with my Go program being in the process table briefly; the goal was
just to not include it in the process chain of the exec'd program. And the
exit code handling is trivial, yes, but a bit undesirable to my mind:
https://stackoverflow.com/a/10385867. Admittedly this is a matter of taste
The way you describe the requirements there is no solution. Not in Go, C,
or any other language. You could try to invert the problem by creating a
pipe, forking your Go program, having the forked copy write to the pipe,
then exec the other program and have it read from the pipe. But that still
leav
I'm looking for a way to exec a process (as in, `execve(2)`) and write
something to its stdin.
Context: I am writing a tool that does some argument processing and then
executes another (arbitrary) program, and passes the processed data to that
other program's stdin. The processed data cannot be
Hello- This is a full time employment, direct hire for a startup I am
helping staff. We are looking for an expert developer. You would be one of
the first 10 people on board developing a groundbreaking serverless super
cloud offering compute 10x lower than the industry. Our DevNet has more
memory i
I suppose the best way is to use namespaced naming for the imported packages
[Joop Kiefte - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=pgu9m)
[pgu9m]
On September 30, 2020 at 17:47 GMT, Denis Cheremisov
wrote:
It is because you import protoc-gen-go generated en
It is because you import protoc-gen-go generated entities with exactly the
same package name and their own name. This is not allowed with protobuf,
you can only have a single .. You can either use
different names for error packages or use a 3rd repository with generated
code.
среда, 30 сентябр
Hi
On Mon, Sep 28, 2020 at 4:45 AM Conrado P. L. Gouvêa
wrote:
>
>
> On Fri, Sep 25, 2020 at 3:01 PM Anatol Pomozov
> wrote:
> > Or more precisely it calls this code
> > https://boringssl.googlesource.com/boringssl/+/master/crypto/fipsmodule/ec/felem.c#57
> >
> > But I want to avoid implementi
server https://github.com/unistack-org/micro-server-grpc
client https://github.com/unistack-org/micro-client-grpc
code used both repos
https://github.com/unistack-org/micro-tests/tree/master/server/grpc
ср, 30 сент. 2020 г. в 16:41, Joop Kiefte :
> This seems to be because the protocol buffer pac
This seems to be because the protocol buffer packages rely on shared state,
kinda similar to the registration of database drivers in database/sql I would
say (correct me if I'm wrong). I don't know how you import them, but you
probably need a way to strictly separate the two in your program (exa
So nobody knows how to deal with this? And if some projects have proto
files with the same name - protobuf always complain about it?
вт, 29 сент. 2020 г. в 10:50, Vasiliy Tolstov :
>
> Hi! I have two packages server and client. All belongs to different
> repos. In this packages i have internal/err
> The current approach of passing them through mostly untouched still allows the
> application to make any decision it wants based on them - and that's where the
> necessary information is anyway.
I like the approach with multi return far more than Darts try, catch etc. My
first thought was that
On Wed, Sep 30, 2020 at 11:27 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Perhaps they haven't because different systems return different ones in
>> different circumstances, but I hope Posix means that isn't the case.
>>
>
> Not all platforms Go runs on are Posix. Pla
On Wed, Sep 30, 2020 at 10:51 AM Kevin Chadwick wrote:
> I feel like a few of these should probably be exposed in the net package?
>
Some are. The point behind the new errors package is that the rest don't
need to :)
Perhaps they haven't because different systems return different ones in
> dif
On 2020-09-29 18:38, Axel Wagner wrote:
> I hope not. If you want to handle a specific error, what you should do is file
> an issue to expose that error as a type (and thus make it part of the API of
> the
> package), not to match strings - precisely *because* they aren't part of the
> stable API,
18 matches
Mail list logo
