bject: Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
> Thank you for your attention and fast reply.
> I added your patch and now observe further errors in the code of shell.c
> Enclosed is a compilation log.
Thanks, I'll look at these. Note that you can get bas
> Thank you for your attention and fast reply.
> I added your patch and now observe further errors in the code of shell.c
> Enclosed is a compilation log.
Thanks, I'll look at these. Note that you can get bash already built
for MinGW.
--
``The lyf so short, the craft so long to lerne.'' - Chauc
@gnu.org
Cc: chet.ra...@case.edu
Subject: Re: shell.c:41:17: fatal error: pwd.h: No such file or directory
On 10/20/15 2:31 AM, Raveh Neeman wrote:
> Hello,
>
>
> I get a compilation error during a build of bash 4.3.30 on MSYS, MinGW.
Try the attached patch.
Chet
--
``The lyf so short,
On 10/20/15 2:31 AM, Raveh Neeman wrote:
> Hello,
>
>
> I get a compilation error during a build of bash 4.3.30 on MSYS, MinGW.
Try the attached patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS
Hello,
I get a compilation error during a build of bash 4.3.30 on MSYS, MinGW.
Enclosed are logs of ./configure and make commands.
Could you fix it or advise a solution/workaround?
Rind Regards,
Raveh Neeman
Freelancer
Codeh Technologies, Yokneam, Israel
mob: +972-544-634-318
log.
Chet Ramey wrote:
but it seemed to work and not be at fault upon further
exploration. Now it's one of 2 Associative arrays (often
called "'map's" in the code where they are used as such)
that is failing due to illegal subscript messages.
The fact that one of the maps works and the other doe
> but it seemed to work and not be at fault upon further
> exploration. Now it's one of 2 Associative arrays (often
> called "'map's" in the code where they are used as such)
> that is failing due to illegal subscript messages.
>
> The fact that one of the maps works and the other does not
> see
I got various suggestions for getting my script to work at boot time,
and any of them might have been applicable before I'd gotten to the current
problem...
In particular the <<<"$VAR" construct where VAR was holding
output from a program.. was something on my "iffy" list,
but it seemed to work
Greg Wooledge wrote:
> The 'read' example will not work as you've written it. The change to
> the shell variable 'out' will be lost when the pipeline terminates.
> (But you can get a very recent bash release and set the "lastpipe"
> shopt to work around this.)
>
> If the while loop also tries to
Greg Wooledge wrote:
read out < <(declare -p "$var")
That code actually isn't called. It's used by "isarray" to tell me whether
or not a var is an array.
The code that doesn't work is the line with the comment "line 233".
(which is now line 235 from the latest error message.
service boo
On Tue, Jul 29, 2014 at 10:21:36PM +0200, Angel wrote:
> What surprises me is that the only use of here-docs (actually
> here-strings) in your script are process substitutions:
> > read out <<<$(declare -p "$var" )
> > while ... done <<<"$(get_net_IFnames_hwaddrs)"
>
> When it looks simpler to wri
Linda Walsh wrote
>
> Andreas Schwab wrote:
> > Linda Walsh writes:
> >
> >>Except that in-line HERE docs don't need to be implemented
> >> through a tmp file unless you want to slow things down.
> >>They should be read out of memory and NOT transfered to
> >> to non-existent, external s
On Tue, Jul 29, 2014 at 12:06:41PM -0700, Linda Walsh wrote:
> Andreas Schwab wrote:
> >You need a file descriptor for your memory storage.
> ---
> Why?
A here-document is a redirection. All it does it change where stdin
comes from. There has to be a place for file descriptor 0 to point to.
This
Andreas Schwab wrote:
Linda Walsh writes:
Except that in-line HERE docs don't need to be implemented
through a tmp file unless you want to slow things down.
They should be read out of memory and NOT transfered to
to non-existent, external storage.
You need a file descriptor
Linda Walsh writes:
> Except that in-line HERE docs don't need to be implemented
> through a tmp file unless you want to slow things down.
> They should be read out of memory and NOT transfered to
> to non-existent, external storage.
You need a file descriptor for your memory storage
Greg Wooledge wrote:
On Fri, Jul 25, 2014 at 04:44:27PM -0700, Linda Walsh wrote:
FWIW, this script DOES work interactively in normal operation.
Just when the system is in pre-single-user state and not
much in the way of resources is available that it blows.
Then you are attempting to use o
On Fri, Jul 25, 2014 at 04:44:27PM -0700, Linda Walsh wrote:
> FWIW, this script DOES work interactively in normal operation.
>
> Just when the system is in pre-single-user state and not
> much in the way of resources is available that it blows.
Then you are attempting to use operating system fea
Chet Ramey wrote:
Maybe you should post your script so readers can take a look. It's
unlikely that there is a bug in here-documents, but it's possible.
If you ask for it... I "inlined" the needed library functions,
so should run standalone.
FWIW, this script DOES work interactively in
On 7/24/14, 10:46 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> Only you can answer questions about where your scripts, and your `system
>> scripts', use process substitution.
>
> I tried to switch to in-line HERE documents instead of
> /dev/fd/62... but those don't work either.
>
> I t
Chet Ramey wrote:
Only you can answer questions about where your scripts, and your `system
scripts', use process substitution.
I tried to switch to in-line HERE documents instead of
/dev/fd/62... but those don't work either.
I thought HERE docs were pretty basic?
Are HERE documents also
Pierre Gaston wrote:
your test will also fail if there is one file named "*" it' better to
just [[ -e ${entries[0]} ]]
Sigh...so you are saying that:
[[ ${entries[0]} == "$1/*" ]] && return 0
would fail if someone has a file named '*'.
Hmmm...and whether the file exists or not, 'entri
On Sat, Apr 5, 2014 at 1:46 PM, Linda Walsh wrote:
>
>
> Chris Down wrote:
>
>> Linda Walsh writes:
>>
>>> So all I need do is test the first entry:
>>>
>>>local -a entries=("$1"/*)
>>>[[ ${entries[0]} == $1/* ]] && return 0
>>>
>>> --- the $1 doesn't need quotes in [[]] and '*' won't exp
Linda Walsh writes:
> Pattern matching? Why doesn't '*' match anything then?
I've no idea what you're doing, but:
$ var='*bar*'
$ [[ abarb = $var ]]
$ echo $?
0
$ [[ aquxb = $var ]]
$ echo $?
1
pgpUZ39g3TPmc.pgp
Description: PGP signature
Chris Down wrote:
Linda Walsh writes:
So all I need do is test the first entry:
local -a entries=("$1"/*)
[[ ${entries[0]} == $1/* ]] && return 0
--- the $1 doesn't need quotes in [[]] and '*' won't expand or
am missing something? Thanks for the tip Pierre, I often
don't see forests b
Linda Walsh writes:
> So all I need do is test the first entry:
>
>local -a entries=("$1"/*)
>[[ ${entries[0]} == $1/* ]] && return 0
>
> --- the $1 doesn't need quotes in [[]] and '*' won't expand or
> am missing something? Thanks for the tip Pierre, I often
> don't see forests because
Greg Wooledge wrote:
On Wed, Apr 02, 2014 at 07:54:58AM +0300, Pierre Gaston wrote:
[[ -d $1 ]] && {
readarray entries<<<"$(cd "$1" && printf "%s\n" * 2>/dev/null)"
((${#entries[@]} < 3)) && return 0
That's unnecessarily complex.
why not simply: entries=("$1"/*) ?
Indeed --
On Wed, Apr 02, 2014 at 07:54:58AM +0300, Pierre Gaston wrote:
> On Wed, Apr 2, 2014 at 6:04 AM, Linda Walsh wrote:
> > Well don't know if it circumvents the /fd/62 prob
> > yet (got a few places more to check & convert),
> > but this seems to work for checking if a file
> > or dir is empty:
> >
>
On Wed, Apr 2, 2014 at 6:04 AM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>
>> On Fri, Mar 28, 2014 at 06:14:27PM -0700, Linda Walsh wrote:
>>
>>> Does read varname <<<$(...) use process substitution?
>>>
>>
>> I wouldn't dare write it like that, because who knows how the parser
>> will treat
Greg Wooledge wrote:
On Fri, Mar 28, 2014 at 06:14:27PM -0700, Linda Walsh wrote:
Does read varname <<<$(...) use process substitution?
I wouldn't dare write it like that, because who knows how the parser
will treat it. I'd write it this way:
read varname <<< "$(...)"
This is a command su
On Fri, Mar 28, 2014 at 06:14:27PM -0700, Linda Walsh wrote:
> Does read varname <<<$(...) use process substitution?
I wouldn't dare write it like that, because who knows how the parser
will treat it. I'd write it this way:
read varname <<< "$(...)"
This is a command substitution and a here-str
Eduardo A. Bustamante López wrote:
On Fri, Mar 28, 2014 at 08:21:40AM -0700, Linda Walsh wrote:
Isn't it only things that are like "read xxx < <(cmd)" ? or is there
something else that uses process substitution??
<(cmd) and >(cmd) are process substitutions. If you want to work
around, use na
On Fri, Mar 28, 2014 at 08:21:40AM -0700, Linda Walsh wrote:
> I just checked... it is partly my fault in that I
> upgraded my bash from 4.2 -> 4.3 to get around a limitation in 4.2.
> Am not looking forward to upgrading to 4.4, since both times I've tried,
> autocompletion completely broke a
On Fri, Mar 28, 2014 at 08:21:40AM -0700, Linda Walsh wrote:
> What I'd prefer to see is that bash do what you say at
> runtime, rather being limited to that choice at build time.
If you require process substitution features in a script that may be
executed when the OS is not fully booted, I
On 3/28/14, 11:21 AM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>> On Thu, Mar 27, 2014 at 07:31:31PM -0700, Linda Walsh wrote:
>>> So whether or not to use /def/fd is a build time option?
>>
>> On many commerical Unix systems (which don't have /dev/fd/), Bash
>> falls back to using named
Greg Wooledge wrote:
On Thu, Mar 27, 2014 at 07:31:31PM -0700, Linda Walsh wrote:
So whether or not to use /def/fd is a build time option?
On many commerical Unix systems (which don't have /dev/fd/), Bash
falls back to using named pipes.
---
Right... but this is a case where
On Thu, Mar 27, 2014 at 07:31:31PM -0700, Linda Walsh wrote:
> So whether or not to use /def/fd is a build time option?
On many commerical Unix systems (which don't have /dev/fd/), Bash
falls back to using named pipes.
> It's a minority of scripts but have noticed the message
> in som
Chet Ramey wrote:
On 3/27/14, 8:42 PM, Linda Walsh wrote:
I certainly wouldn't be against a builtin that would return
the same thing as /dev/fd/62 -- just one that doesn't try to
walk an external path to perform internal functions (have looked
several times at scripts that have shown such mes
On 3/27/14, 8:42 PM, Linda Walsh wrote:
> I certainly wouldn't be against a builtin that would return
> the same thing as /dev/fd/62 -- just one that doesn't try to
> walk an external path to perform internal functions (have looked
> several times at scripts that have shown such messages, and
> ha
When a system is not fully up or limping, various
services like udevd may not be mounted yet -- proc may not be
mounted yet. But it appears there are features in bash that
try to use external paths to access process descriptors in
itself (rather than just using them directly).
If there is a need
On 01/02/2013 06:27 PM, Mike Frysinger wrote:
that ship has already sailed
Sorry for late response, but do you have some link or something? I would
like to track it.
RR
-- Forwarded message --
From: Eric Blake
Date: Wed, 02 Jan 2013 10:41:07 -0700
Subject: Re: No such file or directory
To: Michael Williamson
On 01/02/2013 10:30 AM, Michael Williamson wrote:
> Hi Eric,
>
> Thanks for your explanation. I realize now that I should
&g
ave a complaint. Apparently, when unknowingly attempting to run a
> >>>> 32-bit executable file on a 64-bit computer, bash gives the error
> >>>> message "No such file or directory". That error message is baffling
> >>>> and frustratingly unhelpf
On Wednesday 02 January 2013 09:47:10 Roman Rakus wrote:
> On 01/02/2013 03:31 PM, Eric Blake wrote:
> > On 01/02/2013 07:28 AM, Michael Williamson wrote:
> >> Thanks for your explanation. Now I have another question.
> >> Why is the error message for ENOENT simply
>
On 01/02/2013 03:31 PM, Eric Blake wrote:
On 01/02/2013 07:28 AM, Michael Williamson wrote:
Hi Aharon,
Thanks for your explanation. Now I have another question.
Why is the error message for ENOENT simply
"No such file or directory", when the man page for execve
has this complete d
On 01/02/2013 07:28 AM, Michael Williamson wrote:
> Hi Aharon,
>
> Thanks for your explanation. Now I have another question.
> Why is the error message for ENOENT simply
> "No such file or directory", when the man page for execve
> has this complete description:
>
Hi Aharon,
Thanks for your explanation. Now I have another question.
Why is the error message for ENOENT simply
"No such file or directory", when the man page for execve
has this complete description:
"The file filename or a script or ELF interpreter does not exist,
or a shared
the error
message "No such file or directory". That error message is baffling and
frustratingly unhelpful. Is it possible for bash to provide a better
error message in this case?
It's not Bash. That is the error returned from the OS in errno when
it tries to do an exec(2) of the fil
.
it's the ldso missing. if a lib was missing, the ldso would spit out a useful
message telling you exactly which lib could not be found. at least, that's
the standard Linux (glibc/uclibc/etc...) behavior.
$ ./a.out: error while loading shared libraries: libfoo.so: cannot open shared
object file: No such file or directory
-mike
signature.asc
Description: This is a digitally signed message part.
On 1/1/13 2:49 PM, Aharon Robbins wrote:
> In article ,
> Michael Williamson wrote:
>> Hi,
>>
>> I have a complaint. Apparently, when unknowingly attempting to run a
>> 32-bit executable file on a 64-bit computer, bash gives the error message
>> "No such
In article ,
Michael Williamson wrote:
>Hi,
>
>I have a complaint. Apparently, when unknowingly attempting to run a
>32-bit executable file on a 64-bit computer, bash gives the error message
>"No such file or directory". That error message is baffling and frustratingly
&
Hi,
I have a complaint. Apparently, when unknowingly attempting to run a
32-bit executable file on a 64-bit computer, bash gives the error message
"No such file or directory". That error message is baffling and frustratingly
unhelpful. Is it possible for bash to provide a better error
Greg Wooledge writes:
> If your actual problem is "Find all the files containing the string
> StateRB, and suppress all error messages", then use this:
>
> find . -type f -exec grep -l StateRB {} \; 2>/dev/null
Or with a recent version of find (also POSIX):
$ find . -type f -exec grep -l StateR
On Wed, May 06, 2009 at 04:03:51PM +0200, Roman Rakus wrote:
> On 05/06/2009 02:14 PM, cseguino wrote:
> > $ find . | xargs grep -v "No such file or directory" | grep "StateRB"
> > grep:
> >./Tiger/codebase/netmarkets/jsp/ext/eurocopter/tiger/chang
On Wednesday 06 May 2009 10:03:51 Roman Rakus wrote:
> On 05/06/2009 02:14 PM, cseguino wrote:
> > $ find . | xargs grep -v "No such file or directory" | grep
> > "StateRB" grep:
> > ./Tiger/codebase/netmarkets/jsp/ext/eurocopter/tiger/change/.svn/text
On Wednesday 06 May 2009 08:14:03 cseguino wrote:
> $ find . | xargs grep -v "No such file or directory" | grep "StateRB"
> grep:
> ./Tiger/codebase/netmarkets/jsp/ext/eurocopter/tiger/change/.svn/text-base/
>Copy: No such file or directory
>
On 05/06/2009 02:14 PM, cseguino wrote:
Hello,
I'm executing the following command using cygwin :
$ find . | xargs grep -v "No such file or directory" | grep "StateRB"
grep:
./Tiger/codebase/netmarkets/jsp/ext/eurocopter/tiger/change/.svn/text-base/Copy:
Hello,
I'm executing the following command using cygwin :
$ find . | xargs grep -v "No such file or directory" | grep "StateRB"
grep:
./Tiger/codebase/netmarkets/jsp/ext/eurocopter/tiger/change/.svn/text-base/Copy:
No such file or directory
grep: of:
57 matches
Mail list logo
