Hello all,
I have been experimenting with redirection of stan-
dard I/O of child processes using FreePascal 2.4.2
on Windows. I have succeeded in capturing standard
input and standard output, but failed to feed my own
data to the child's standard input.
The child process doesn't seem to rec
SteveG:
> Anton - I have attached an extract from some work-
> ing code (hopefully I didnt remove anything neces-
> sary)
> It may help you move on a bit further
I turned your piece of code into a complete program,
but it didn't work either. In fact, there is not
much difference between yo
SteveG:
> This is working on Linux and WinXP
>
> I cut what I was hoping was just the relevant code
> from the unit, so it is missing a bit :)
Here's a full program made from this code:
http://pastebin.com/id90J1rY
It doesn't work for me in WinXP. What about you?
Anton
Marco van de Voort:
> Why do you execute over the shell? You now pipe
> your information into the shell (since that is
> what you execute directly), not the program.
Thanks for the note, Marco. Unfortunately, replacing
that line with the direct path to more.com had no
effect.
When exe
Marco van de Voort:
> > When executing command-line programs via the
> > shell, isn't the shell's input redirected to the
> > program's?
>
> Maybe. I'm pretty sure about batchfiles, but never
> tried programs, that's why I thought I'd mention
> the observation.
My program captures both the
Marco van de Voort:
> I played a bit with it, but was unable to make it work. I
> added a writeln of outstream.size to the "running" while,
> and it seems output is written.
Many thanks :)
If I understood you correctly, you put
WriteLn(MoreProcess.Output.Size);
inside the waiting loop an
Ludo Brands:
> If you run 'more' in a cmd window you'll notice that
> 'more' echoes the input but only sends to stdout when a
> return is entered. I modified the program to send
> 'Anton'#10 and the program reads back 'Anton'#10 from
> stdout.
Thank you, Ludo, this is great
Ludo Brands:
> If you run 'more' in a cmd window you'll notice that
> 'more' echoes the input but only sends to stdout when a
> return is entered. I modified the program to send
> 'Anton'#10 and the program reads back 'Anton'#10 from
> stdout.
Connected with this remark, is
waldo kitty:
> how about sending the ^Z line the CRLF is being sent to
> indicate line breaks??
This I had tried even before posting the question :)
Ludo Brands:
> I don't see where you close the mProcess.input.
In my original post I call:
MoreProcess.CloseInput();
As for the progra
Ludo Brands:
> > Connected with this remark, is there a way to get the
> > underlying StdIn handle in a FreePascal program, so as
> > to read from it per-character, or any other way using
> > the OS's routines?
>
> The handles are mProcess.Input.Handle and mProcess.Out-
> put.Handle
I
I wrote:
> I'll try duplicating the handles and report the results.
Yes. It works now. I am creating a non-inheritable handle
using CreatePipe, then duplicating it to an inheritable one
using DuplicateHandle and pass the duplicate to the
CreateProcess funtion.
Does this mean that th
Ludo Brands:
> You can file a bug at http://bugs.freepascal.org/
OK.
> Dupicating handles isn't apparently the only solution. The
> msdn sample creates non-inheritable pipes and hands these
> handles simply over to createprocess, without duplicating.
There are two solutions, but only of them
Ludo Brands:
> If you need these handles from the child process use:
> InHnd:=GetStdHandle(STD_INPUT_HANDLE);
> OutHnd:=GetStdHandle(STD_OUTPUT_HANDLE);
> ErrHnd:=GetStdHandle(STD_ERROR_HANDLE);
Thank you, that's what I need.
By the way, it does work in a simple single-process applica-
tion:
In addition to what Mattias has said,
the following works pretty well:
Program StrTest;
Var a:Pchar;
Begin
a:=PChar(nil);
Reallocmem(a,20); //ko
a[0] := 'A';
a[1] := 'n';
a[2] := 't';
a[3] := Chr(0);
WriteLn('Done: ', a);
End.
Anton
___
fpc-pascal mail
Rainer Stratmann:
> Alternatively you can make a class or an object with the
> text variable in it.
But if you need to work with only one file, you can get rid
of a global variable in the main module by just extracting
the relevant functions and the file handle into a separate
unit:
-
oad(void) DLL;
PSylPluginInfo plugin_info (void) DLL;
GInt plugin_interface_version (void) DLL;
static SylPluginInfo info =
{ "Test Plugin",
"0.0.1",
"Anton Shepelev",
"It had better work"
};
void plugin_load(void)
{ prin
Jonas Maebe:
> One likely potential cause is the fact that released FPC
> versions enable all floating point exceptions. Since libc
> does not do that, many C programs and frameworks contain
> invalid floating point operations.
Wow! Many thanks. I thought that information would be use-
les
A little update on the subject.
Ludo Brands wrote:
> If you run 'more' in a cmd window you'll notice that
> 'more' echoes the input but only sends to stdout when a
> return is entered. I modified the program to send
> 'Anton'#10 and the program reads back 'Anton'#10 from std-
>
Ludo Brands:
> You can file a bug at http://bugs.freepascal.org/.
This is bug #0019325.
...
I thought about writing a patch, but it seems that it is not
enough to modify the implementation of the Windows-specific
pipes.inc.
The correct way to create pipes for the three channels (out,
in and er
Michael Van Canneyt:
> The interface of the pipes unit can be changed
> with a parameter with a default value, so existing
> code continues to work.
Yes, but all the platform-specific pipe.inc files
and pipes.pp will have to be changed anyway because
the CreatePipeHandles will have a di
Sorry, I forgot to say the patch is against verstion
2.4.2.
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hello all,
I have installed FPC on a Linux machine to find that in the
virtual terminal (true text-mode, not GUI-based emulator)
FP-IDE does not dispaly pseudographics correctly. It turned
out that changes to the SFM (Screen Font Map) doesn't have
any effect inside the IDE, and I count'd un
Nikolay Nikolov:
> Modern FPC versions should support UTF-8 output for the
> IDE. I made a patch for this, that was included in fpc
> 2.4.2 IIRC. Which FPC version are you using and on which
> linux distro/version? What is the value of the LANG envi-
> ronment variable?
I am using FPC 2
Nikolay Nikolov:
> Try changing it to LANG=en_US.UTF-8
Thank you very much, it works well now. Maybe this
should be mentioned on the WIKI?
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/
Graeme Geldenhuys:
> You are welcome to add it to the wiki.
I still do not fully understand the problem, so
please, review what I have come up with:
On Linux/Unix the FP-IDE calculates the
addresses of the drawing charactes (also
called pseudagraphics) based on the
Nikolay Nikolov:
> Basically, all it does is, it checks if the LANG
> variable contains ґUTF-8' as a substring (not sure
> if it is the right way to do it, but it works for
> Fedora, Ubuntu, OpenSUSE, Mandriva and latest
> Debian) and if it does, it writes UTF-8 characters
> to the console
Nikolay Nikolov:
> [kbd_mode] only works on the linux console. It
> doesn't work under xterm, gnome-terminal, konsole,
> etc and we still need a way to detect if they are
> in UTF-8 mode or not.
But at least that will make the IDE work correctly
in the true console... As for the graphical
Hello all,
I have a plain Windows DLL made in Visual Studio C++
and working with other C applications. When I try
to statically import it into an FPC program I get
the following error:
An unexpected error occurred while initializ-
ing an application 0xc034
When using it dynami
Ludo Brands:
> Both errors indicate that the dll couldn't be
> loaded. Or the dll itself isn't found, or the dll
> has dependencies (probably c libraries) that
> aren't found.
The DLL does work on another PC, so the problem must
be with some dependencies. Many thanks. But how
can
Ludo Brands:
> Both errors indicate that the dll couldn't be
> loaded. Or the dll itself isn't found, or the dll
> has dependencies (probably c libraries) that
> aren't found.
OK, I have found the missing dependency using
the "Dependency Walker" utility.
Thank you,
Anton
_
Brian:
> What's driving me crazy is that running the two
> commands via ExecuteProcess does the first step
> OK, but oggenc fails with an exit code of 1, oper-
> ation not permitted.
>
> If I replace the ExecuteProcess with a call to
> fpSystem, concatenating the CommandString and
>
Andrew Haines:
> I suspect that the oggenc command is failing
> because TProcess behind the scenes is splitting
> --output="outputfile.ogg" into two params.
Yes, indeed. It is also mentioned on the WIKI:
http://wiki.freepascal.org/Executing_External_Programs
(see section
"Para
Marco van de Voort:
> It should now be possible to pass the parameters
> to tprocess separated. I don't remember if that
> change made it to 2.4.4 though, otherwise it will
> be in 2.6.0.
Thanks for letting me know.
Is the parameter separation algorithm intentionally
made to split par
Felipe Monteiro de Carvalho:
> It does not split partially quoted arguments AFAIK
> Not sure about Free Pascal Trunk however.
>
> If FPC Trunk also does not support this, then I'm
> sure a patch to improve StringToPPChar would be
> welcome.
Version 2.4.4 does split
Felipe Monteiro de Carvalho:
> If FPC Trunk also does not support this, then I'm
> sure a patch to improve StringToPPChar would be
> welcome.
I have created issue # 0020279.
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://l
Marco van de Voort:
> So basically this bugreport is about adding *nix
> shell quoting to a routine that was meant to mimic
> WINDOWS API (iow not even Windows shell) be-
> haviour.
I only wanted to fix the parsing of partially quoted
parameters. Of course, it is best to deprecate this
f
Marcos Douglas:
> It's not difficult, but is boring have always a
> parameter or function return to return an error,
> and have to verify if error then... if not er-
> ror... if error and error then... etc
If you mean having to write nested IFs to check all
the errors, then there are
Timothy Groves:
> Can anyone think of a situation in which you would
> *have* to use forward declared functions? I'm
> trying to come up with an example for such for my
> book, and I am drawing a blank.
Pascal User Manual and Report says:
Procecure (function) identifiers may be used be
Hello, all.
According to Borland's official language guide to
Turbo Pascal 7.0,
To be used as procedural values, procedures and
functions must be declared with a 'far' directive
or compiled in the '{$F+}' state.
whereas Free Pascal in -Mtp seems to accept any non-
system procedure
Sven Barth to Anton Shepelev:
>>According to Borland's official language guide to
>>Turbo Pascal 7.0,
>>
>> To be used as procedural values, procedures and
>> functions must be declared with a 'far' direc-
>> tive or compiled in the '
I wrote:
>According to Borland's official language guide to
>Turbo Pascal 7.0,
>
> To be used as procedural values, procedures and
> functions must be declared with a 'far' directive
> or compiled in the '{$F+}' state.
>
>whereas Free Pascal in -Mtp seems to accept any
>non-system proced
Karoly Balogh to Anton Shepelev:
>>According to Borland's official language guide to
>>Turbo Pascal 7.0,
>>
>> To be used as procedural values, procedures and
>> functions must be declared with a 'far' directive
>> or compiled in the '
Karoly Balogh to Anton Shepelev:
>>But this is from the Language guide -- a document
>>that descrbes the language in a platform-agnostic
>>way...
>
>Then you have a very different TP manual than me.
>Mine is really only for the specific 16-bit case,
>and
I miswrote:
>Karoly Balogh to Anton Shepelev:
Beg your pardon for the misattribution, Marco.
--
Please, do not forward replies to the list to my e-mail.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-
Sven Barth:
> The modes are for the case have code written for
> other compilers (TP, MacPas, Delhi, ISO) work in
> FPC (as good as reasonably possible). We do howev-
> er *not* guarantee that code written in one of
> these modes with FPC compiles or runs with the
> corresponding compi
Marco van de Voort to Anton Shepelev:
> > I have a related question which seems unworthy
> > of a new thread. I can't compile this program
> > with -Miso:
> >
> > Program Test;
> > var object: integer;
> > begin
> > end.
>
Hello, all
The documentation on the FILE and TEXT types says
that "nothing prevents the programmer, from writing
a file driver that stores its data for instance in
memory." Is there a more detailed instruction or an
example illustrating how to do it?
--
Please, do not forward replies to m
Marco van de Voort to Anton Shepelev:
> > The documentation on the FILE and TEXT types
> > says that "nothing prevents the programmer, from
> > writing a file driver that stores its data for
> > instance in memory." Is there a more detailed
> > in
Hello, all
Can anybody suggest why the function
function FpWaitPid
( pid: TPid;
var Status: cint;
Options: cint
): TPid;
may return the status multiplied by 256? If my child pro-
cess terminates with Halt(1), the status is 256, if with
Halt(2),
Bernd Oppolzer:
> The story is documented in more detail here (including the
> Pascal source code of the rounding function):
>
> http://bernd-oppolzer.de/job9i032.htm
Wirth introduced the capitalisation of keywords, and you
have decided to invert his style and capitalise everything
except k
Marco van de Voort to Anton Shepelev:
> > may return the status multiplied by 256? If my child
> > process terminates with Halt(1), the status is 256, if
> > with Halt(2), the status is 512, etc.
>
> Entirely normal. Status is an opague format in POSIX, and
> t
Hello, all
I don't know a better place to ask this, and beg your pardon
for an off-topic post.
The Language Guide for Turbo Pascal 7.0 has this to say
about `inline' statements and proceudres:
When a normal procedure or function is called, the com-
piler generates code that pushes the pr
Florian Klampfl to Anton Shepelev:
> > What about the other registers -- does Turbo Pascal take
> > care of them, perhaps enveloping each expansion of an
> > inline procedure into a POPs and PUSHes?
>
> No.
Thank you for the reply, Florian. Does that mean that I
Tomas Hajny:
> There are 3rd party Pascal units supporting work with
> other archive formats (mostly listing and decompression)
> either using shared libraries, or containing direct
> implementation of certain functionality (there has been
> e.g. unrar.pas containing a port of the original C
> imp
54 matches
Mail list logo
