| Re: redirect stdout and stderr to PHP variables? [message #176854 is a reply to message #176842] |
Sat, 28 January 2012 23:40   |
M. Strobel
Messages: 386
Registered: December 2011
Karma:
|
Senior Member |
|
|
Am 28.01.2012 13:03, schrieb crankypuss:
> On 01/27/2012 04:25 AM, M. Strobel wrote:
>> Am 27.01.2012 11:22, schrieb crankypuss:
>>> On 01/25/2012 03:52 PM, Peter H. Coffin wrote:
>>>> On Wed, 25 Jan 2012 12:47:11 -0700, crankypuss wrote:
>>>> > I'm sure there's a way to do this, probably some simple syntax I've not
>>>> > run into and am too stupid to find in the manual or through google-fu or
>>>> > otherwise.
>>>> >
>>>> > I'd like to issue an arbitrary shell command in a subroutine and have it
>>>> > return an array that contains one element representing stdout and
>>>> > another element representing stderr.
>>>> >
>>>> > For example, using tar to deal with a bazillion files, error messages
>>>> > might not be seen when specifying verbose output; I'd like to collect
>>>> > them and display after stdout.
>>>> >
>>>> > I've not found any syntax, yet, for redirecting to a PHP variable rather
>>>> > than some file.
>>>>
>>>> Sorry, you have to use the file, then read the file if you want to parse
>>>> back in what went out on stderr.
>>>
>>> Actually no, I do not have to use no steenking files, I might have to start writing
>>> something from scratch in freaking assembler, but I don't have to use no steenking
>>> files to do something that hasn't the least thing to do with files.
>>>
>>> Thank you though, and apologies for any crankiness that has leaked into my post...
>>> I'm going through the transition from many years of Windows to using Linux, and
>>> although I mostly like it, I find the tendency for scripts to rely on command output
>>> run through pipes to be abhorrent since the whole concept of validity checking goes
>>> out the window when you swallow that paradigm, and writing a file when it isn't
>>
>> Can you expand on that? There must be a misunderstanding, the command you run does
>> all validity checking, me thinks.
>
> Look at any bash script longer than about 4 lines. You'll find it issuing some
> command and running it through sed or whatever and then through the next stage of the
> pipe and basically *assuming* that command output formats never change and nothing
> can go wrong go wrong.
>
It just fits. And no magic, only some basic principles.
/Str.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]