On 8/8/2017 10:59 AM, Nellis, Kenneth wrote:
> SHTDI and, sadly, such a task is not in my skill set.)
>
Nothing like attempting to do it to add skills to your set. This isn't
a valid reason not to do it. It is only a valid reason that it would
take longer than someone else who might attempt it,
Wouter van Doorn writes:
> I've run into a problem regarding pipes in bash, in a command that
> loops. I've reduced it to a very small one-liner that fails.
WJFFM. Unless it's down (again) to your somewhat bizarre PATH settings,
you're most likely looking at some BLODA that tries to follow each
f
> From: Eliot Moss
> It also works for me. If it is not a version issue, then I
> wonder about BLODA. Maybe anti-virus or similar tools are
> wrapping process creation in such a way that things get
> confused. Try cygcheck, etc.
BTW, it also works for me.
With so many Cygwin issues being attr
On 8/8/2017 10:20 AM, Ronald Fischer wrote:
TWO - this fails, apparently (warning: my guess) at the pipe
$ for j in 1 2;do echo $j $(echo hello | cat);done
1
2
This works for me:
$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello
It also works for me. If it is not a version
>
> TWO - this fails, apparently (warning: my guess) at the pipe
> $ for j in 1 2;do echo $j $(echo hello | cat);done
> 1
> 2
This works for me:
$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello
I have:
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
Ronald
--
Pr
>
> TWO - this fails, apparently (warning: my guess) at the pipe
> $ for j in 1 2;do echo $j $(echo hello | cat);done
> 1
> 2
This works for me:
$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello
I have:
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
Ronald
--
Ro
Hi all,
I've run into a problem regarding pipes in bash, in a command that
loops. I've reduced it to a very small one-liner that fails. The two
versions below should, I'm sure, give the same output - but they
don't. I know the command is silly and useless as it is shown here,
but it's what I'm lef
Am 20.10.2016 um 21:06 schrieb Evgeny Grin:
Hi!
Noticed some time ago: most of subshells lost colors and prints some codes.
Sample output:
User@PcName ~
$ dash
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\
Hi!
Noticed some time ago: most of subshells lost colors and prints some codes.
Sample output:
User@PcName ~
$ dash
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$ exit
User@PcName ~
$ ash
\[\e]0;\w\a\]\n
On 3 November 2010 09:52, Oleksandr Gavenko wrote:
> On 03.11.2010 11:14, Marco Atzeri wrote:
>>
>> --- Mer 3/11/10, Oleksandr Gavenko ha scritto:
>>
>>> I can turn on subshell by:
>>>
>>> $ mc -U
>>>
>>> This is useful by defaul
Marco Atzeri yahoo.it> writes:
> following mc websites
> "Latest released version: 4.7.4; what's new.
>
> Latest released stable version: 4.7.0.9; what's new in the stable release. "
> and also:
> http://www.midnight-commander.org/wiki/ReleaseWorkflow
>
> But as Pavel is not releasing new pack
--- Mer 3/11/10, SZABO Gergely ha scritto:
> Marco Atzeri yahoo.it> writes:
>
> > That is a workaround, it will be better if
> > Pavel release a mc cygwin package without
> > this problem...
> >
> > mc-4.6.1 is 22 months old and eventually 4.7.0.x
> works
> > better.
> >
> > Regards
> > Mar
Marco Atzeri yahoo.it> writes:
> That is a workaround, it will be better if
> Pavel release a mc cygwin package without
> this problem...
>
> mc-4.6.1 is 22 months old and eventually 4.7.0.x works
> better.
>
> Regards
> Marco
>
>
You might be interested, mc 4.7.5 is coming out within a few
--- Mer 3/11/10, SZABO Gergely ha scritto:
> Marco Atzeri yahoo.it> writes:
>
> >
> > --- Mer 3/11/10, Oleksandr Gavenko ha scritto:
> >
> > > I can turn on subshell by:
> > >
> > > $ mc -U
> > >
> > > This is us
Marco Atzeri yahoo.it> writes:
>
> --- Mer 3/11/10, Oleksandr Gavenko ha scritto:
>
> > I can turn on subshell by:
> >
> > $ mc -U
> >
> > This is useful by default or I miss something?
> >
> >
>
> It is useful but there is
On 03.11.2010 11:14, Marco Atzeri wrote:
--- Mer 3/11/10, Oleksandr Gavenko ha scritto:
I can turn on subshell by:
$ mc -U
This is useful by default or I miss something?
It is useful but there is one problem on cygwin.
When you close mc the subshell will not exit, so you will finish
--- Mer 3/11/10, Oleksandr Gavenko ha scritto:
> I can turn on subshell by:
>
> $ mc -U
>
> This is useful by default or I miss something?
>
>
It is useful but there is one problem on cygwin.
When you close mc the subshell will not exit, so you will finish
with
I can turn on subshell by:
$ mc -U
This is useful by default or I miss something?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml
--subshell
bash-3.2$ ps <<<< in MC >>>>
PIDPPIDPGID WINPID TTY UIDSTIME COMMAND
4056 14056 4056? 1003 09:42:56 /usr/bin/mintty
5164056 516 19928 1003 09:42:56 /usr/bin/bash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mark J. Reed on 2/17/2009 12:17 PM:
> On Tue, Feb 17, 2009 at 2:11 PM, Tim McDaniel wrote:
>> I think that, out of the box, <(...) doesn't work under Cygwin. We had to do
>>ln -s /proc/self/fd /dev/fd
>
> FYI, I have that symlink in
On Tue, Feb 17, 2009 at 2:11 PM, Tim McDaniel wrote:
> I think that, out of the box, <(...) doesn't work under Cygwin. We had to do
>ln -s /proc/self/fd /dev/fd
FYI, I have that symlink in a vanilla Cygwin 1.5 install...
--
Mark J. Reed
--
Unsubscribe info: http://cygwin.com/ml/#unsub
On Tue, 17 Feb 2009, Brian Ford wrote:
$ uname -a
CYGWIN_NT-5.1 PC1163-8460A-XP 1.7.0(0.193/5/3) 2009-02-09 22:27 i686
Cygwin
Just curious if the following is known behavior?
$ echo a | tee >(wc)
a
tee: /dev/fd/63: Bad file descriptor
$ 0 0 0
The bash term is "Process Subs
$ uname -a
CYGWIN_NT-5.1 PC1163-8460A-XP 1.7.0(0.193/5/3) 2009-02-09 22:27 i686
Cygwin
Just curious if the following is known behavior?
$ echo a | tee >(wc)
a
tee: /dev/fd/63: Bad file descriptor
$ 0 0 0
--
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation
Sorry, it should have been #! (beginners mistake, I guess)
Thanks,
Greg
On Fri, 12 Mar 2004, Christopher Faylor wrote:
> On Fri, Mar 12, 2004 at 01:49:27PM -0600, Gregory Borota wrote:
> >#/bin/bash
> >echo Silly
> >( sleep 50 &
> > ( sleep 50 ) )
> >
On Fri, Mar 12, 2004 at 01:49:27PM -0600, Gregory Borota wrote:
>#/bin/bash
>echo Silly
>( sleep 50 &
> ( sleep 50 ) )
>wait
>
>each subshell is "sh.exe".
Why would bash arbitrarily choose "sh.exe" as the subshell?
>I want to be be "bash.exe
#/bin/bash
echo Silly
( sleep 50 &
( sleep 50 ) )
wait
each subshell is "sh.exe". I want to be be "bash.exe". How do I force that
without having to write bash -c
Thanks,
Greg
P.S. Looked at cygwin faq, archive, didn't find the answer although this
I would thi
On Mon, 25 Aug 2003, mike808 wrote:
> In base-files-2.2-1, the following was recently changed:
>
> > # Run all of the profile.d scripts
> > # Note that these are supplied by separate packages
> > /bin/find /etc/profile.d -iname '*.sh' -type f | while read f; do
> > if [ -f "$f" ]; then
> > .
In base-files-2.2-1, the following was recently changed:
> # Run all of the profile.d scripts
> # Note that these are supplied by separate packages
> /bin/find /etc/profile.d -iname '*.sh' -type f | while read f; do
> if [ -f "$f" ]; then
> . "$f"
> fi
> done
Previously, the find was exec
28 matches
Mail list logo
