Am 30.01.2017 11:07 schrieb "Lars" :
>
> On Mon, January 30, 2017 1:06 am, Marco van de Voort wrote:
> >> Reason I want to avoid TProcess is simply because cgi programs being
> >> around 30-100K are easier to upload for people with limited internet
> >> connection speeds. As soon as I pull in large
On Mon, January 30, 2017 1:06 am, Marco van de Voort wrote:
>> Reason I want to avoid TProcess is simply because cgi programs being
>> around 30-100K are easier to upload for people with limited internet
>> connection speeds. As soon as I pull in large units that involve lots
>> of classes the cgi
On Mon, January 30, 2017 12:57 am, Marco van de Voort wrote:
>
>> Or, get assignstream working on windows and not just unix, but that
>> will be a bit of a big undertaking, and again may not be possible.
>
> Again, duplicating TProcess.
>
Except assignstream doesn't require TProcess.Create and Fre
In our previous episode, Lars said:
> > Executeprocess doesn't support piping. It orignally was mainly meant as a
> > portable dos.exec with parameters passed separately and without string
> > length limits, implementable on RTL level.
>
> But doesn't all processes report to stderr?
Afaik there
In our previous episode, Lars said:
> > Indeed, that is one of the big differences between TProcess and
> > ExecuteProcess. I use TProcess often to execute something and then
> > capture the output results. fpGUI's example IDE (Maximus) shows how it
> > can be done with TProcess.
>
> Well I may m
Lars wrote:
> Calling the shell is useful for not requiring absolute paths to
> commands... which is why I like fpSystem...
Never ship a program that uses fpSystem for that purpose, because it's
one of the most basic security holes you can have:
https://www.securecoding.cert.org/confluence/pages/v
Lars wrote:
> But doesn't all processes report to stderr?
> Ones that are created in a program do not report to stderr?
>
> The OS makes it optional if you want to report to stderr? Interesting..
Every process (on Windows: every non-GUI process) on maintstream OSes
(and on many non-mainstream O
On Sun, January 29, 2017 3:18 am, Marco van de Voort wrote:
> In our previous episode, Lars said:
>
>> Assign(StdErr, 'somefile.txt')
>> Rewrite(StdErr)
>>
>>
>> And didn't seem to work
>>
>>
>> So if you run a process and nothing prints to stdout, and there is some
>> data printed to stderr, I do
On Sun, January 29, 2017 10:46 am, Graeme Geldenhuys wrote:
> On 2017-01-29 07:59, Lars wrote:
>
>> So if you run a process and nothing prints to stdout, and there is some
>> data printed to stderr, I do not know how to capture it. Which makes
>> me want to try TProcess instead
>
>
> Indeed, that
On Sun, January 29, 2017 2:41 pm, Marco van de Voort wrote:
> Some likely scenarios (e.g. run and capture stdout) have been prepared in
> RunCommand, also in unit Process.
>
>
> The main motivation for adding these is that 90+% of the TProcess and
> CreateProcess usage in the forums was faulty (sp
On Sun, January 29, 2017 1:36 pm, Santi wrote:
> Maybe ExecuteProcess is calling some kind of shell,
> Freepascal developers will tell.
>
To call the shell you send in cmd /C
FpSystem does this, but it's on unix
Calling the shell is useful for not requiring absolute paths to
commands... which
In our previous episode, Santi said:
> and people nowadays love to name directories and files with strings that
> instead of titles look like abstracts.
>
> In delphi and other languages I've hit may times the 260 character limit
> in windows running a Shell or using ShellApi (I supposed the li
El 27/01/17 a las 18:24, Graeme Geldenhuys escribió:
If you have a huge list of parameters, RunProcess() - at least under
Windows - will most likely hit a 260 character limit, and then fail to
actually execute. I don't actually know where that 260 limit originates
from (Windows API, Command Promp
On 2017-01-29 07:59, Lars wrote:
> So if you run a process and nothing prints to stdout, and there is some
> data printed to stderr, I do not know how to capture it. Which makes me
> want to try TProcess instead
Indeed, that is one of the big differences between TProcess and
ExecuteProcess. I use
In our previous episode, Lars said:
> Assign(StdErr, 'somefile.txt')
> Rewrite(StdErr)
>
> And didn't seem to work
>
> So if you run a process and nothing prints to stdout, and there is some
> data printed to stderr, I do not know how to capture it. Which makes me
> want to try TProcess instead,
On Fri, January 27, 2017 10:24 am, Graeme Geldenhuys wrote:
> On 2017-01-26 14:28, Michael Van Canneyt wrote:
>
>> TProcess gives you full access to the process. You can kill it,
>> pause it, write to stdin, read from stdout.
>>
>> These things cannot be done with RunProcess.
>> That's one-shot and
On Thu, January 26, 2017 7:28 am, Michael Van Canneyt wrote:
>
>
> On Thu, 26 Jan 2017, Graeme Geldenhuys wrote:
>
>
>> Hi,
>>
>>
>> Whats the differences or pros and cons between using TProcess vs
>> RunProcess().
>>
>
> TProcess gives you full access to the process. You can kill it,
> pause it,
In our previous episode, Graeme Geldenhuys said:
> >
> > if you are talking about executeprocess, test again with trunk.
>
> At the moment we are using FPC 2.6.4 and might move to FPC 3.0.2 when
> that is final. Not using Trunk I'm afraid.
>
> Was the 260 char limit removed/fixed in FPC trunk?
On 2017-01-27 17:43, Marco van de Voort wrote:
>
> Which runprocess are you talking about? I know a process.runcommand and a
> sysutils.executeprocess, but not a runprocess.
Apologies, our code is RunProcess(), which internally calls
SysUtils.ExecuteProcess()
>
> if you are talking about execu
In our previous episode, Graeme Geldenhuys said:
> > pause it, write to stdin, read from stdout.
> >
> > These things cannot be done with RunProcess.
> > That's one-shot and wait till it exits.
>
> Another difference simply so others might learn from this discussion
> (like I did).
> If you
On 2017-01-26 14:28, Michael Van Canneyt wrote:
> TProcess gives you full access to the process. You can kill it,
> pause it, write to stdin, read from stdout.
>
> These things cannot be done with RunProcess.
> That's one-shot and wait till it exits.
Another difference simply so others might
On 2017-01-26 14:28, Michael Van Canneyt wrote:
> These things cannot be done with RunProcess.
> That's one-shot and wait till it exits.
Perfect and very handy to know the difference. Thanks for the explanation.
Regards,
Graeme
___
fpc-pascal mail
On Thu, 26 Jan 2017, Graeme Geldenhuys wrote:
Hi,
Whats the differences or pros and cons between using TProcess vs
RunProcess().
TProcess gives you full access to the process. You can kill it,
pause it, write to stdin, read from stdout.
These things cannot be done with RunProcess.
That's
23 matches
Mail list logo
