Re: Could bash do what make does?
You have gone to some trouble with your answer Eduardo, and thanks for that but really you are arguing against a proposition that I have not put and I do not want other readers to be mislead. I am asking about shell scripting of software builds, something that is perfectly possible to do and once must have been the common way. I do not want to see make reimplemented inside bash. Sure, that sounds silly. I think some other contributors have understood my question even without the clarification that has been made. I personally don't mind talking about the related but distinct things that you have raised but I think it would be a wrong to do that in this forum. On 4 December 2016 at 04:07, Eduardo Bustamante wrote: > "build market"? What are you talking about? make was created with the > sole purpose of build automation. The shell was created to provide a > "human interface" to computer operators. These are very specific and > different purposes. Are you going to start asking next to re-implement > vi inside bash? to re-implement a mail user agent? a C compiler? Where > do you draw the line? Read: > http://www.catb.org/jargon/html/C/creeping-featurism.html > > I doubt anyone is willing to go through the effort to re-implement all > the features that make provides, just because one guy thinks "it's > obsolete" -- it's not, by the way. make is very alive. Also, it is > part of the POSIX international standard. so any operating system that > claims to be compatible with UNIX must provide it, see [1] and [2] and > [3]. > > Also remember that nothing makes a stronger argument than patches. If > you want to see this feature implemented, I suggest that you start > looking into the features make provides, and send patches to add said > functionality to bash. > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html > [2] https://www.gnu.org/software/make/ > [3] http://lists.gnu.org/archive/html/bug-make/ >
Re: Could bash do what make does?
On Mon, Dec 05, 2016 at 11:37:11PM +1100, Robert Durkacz wrote: > I am asking about shell scripting > of software builds, something that is perfectly possible to do and once > must have been the common way. Based on what evidence? Show me a shell script created to build a software project without make or ant or any other build tool. Just one. You started out arguing that "bash could do what make does". It can't, of course, and people have told you this, but you do not listen. So next you argued that since make is newer than bash, people must have done builds in bash before make was invented. I disproved this by showing you the release dates of bash and make. Then you argued that you really meant the Bourne shell, not bash, because you have absolutely NO idea how different bash is from the original Bourne shell. And then YOU YOURSELF dug up a release date for the Bourne shell, which was STILL LATER then the release date of make. Now, having argued yourself into a hole, you claim that people "must have" used shell scripting (in a shell that did not exist yet) before they used make, because you simply refuse to accept reality. So, show us your evidence. Put up or shut up.
Re: Filename completion causes doubling of initial ':' character
On 12/4/16 8:14 PM, L A Walsh wrote: > Chet Ramey wrote: >> The short answer is that colon is special to readline: it breaks words for >> the readline completion code. If you want to complete filenames beginning >> with a colon, either quote the colon or remove colon from $COMP_WORDBREAKS. >> If you're using bash-completion, it may have its own problems with colons. > Does readline have any config element in .inputrc to allow specifying > what the word-break characters are as 'isearch-terminators' can specify > a list of characters that terminate an incremental search or IFS specifies > a list of characters that will be used to split a line into words? Applications can use various mechanisms to specify the characters that should break words for the readline word completer. It's an application- specific setting, since different applications have different syntax. Bash happens to use the COMP_WORDBREAKS variable, which is reflected as the value of readline's rl_completer_word_break_characters variable. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
[BUG] a race condition in add_history() leads to SIGSEGV
This was encountered with bash.
- bash: 2.05b
- readline: 4.3
- FreeBSD 8.4 / amd64
Yeah... the version of bash is old, but it seems add_history() in history.c
hasn't changed much in the master / devel branches at
http://git.savannah.gnu.org/cgit/readline.git.
The race condition is that "history_length" gets updated before the
"the_history" update is completed.
In several cases we've encountered, "bash" got a signal (SIGHUP), which
interrupted add_history(), leaving "the_history" and "history_length"
inconsistent. In the signal handling path, it tried to access "the_history" in
history_do_write() in histfile.c, which tried to de-reference a NULL pointer.
Here is a proposed patch for add_history() in history.c:
--
const char *string;
{
HIST_ENTRY *temp;
+ int temp_length = history_length;
if (history_stifled && (history_length == history_max_entries))
{
[...]
history_size = DEFAULT_HISTORY_GROW_SIZE;
the_history = (HIST_ENTRY **)xmalloc (history_size * sizeof
(HIST_ENTRY *));
- history_length = 1;
+ temp_length = 1;
}
else
{
[...]
the_history = (HIST_ENTRY **)
xrealloc (the_history, history_size * sizeof (HIST_ENTRY *));
}
- history_length++;
+ temp_length++;
}
}
[...]
temp = alloc_history_entry ((char *)string, hist_inittime ());
- the_history[history_length] = (HIST_ENTRY *)NULL;
- the_history[history_length - 1] = temp;
+ the_history[temp_length] = (HIST_ENTRY *)NULL;
+ the_history[temp_length - 1] = temp;
+ /* Delay the length update until the history update is complete. */
+ history_length = temp_length;
}
/* Change the time stamp of the most recent history entry to STRING. */
--
Hong.
Re: [Bug-readline] [BUG] a race condition in add_history() leads to SIGSEGV
On 12/4/16 7:42 PM, Hong Cho wrote: > > The race condition is that “history_length” gets updated before the > “the_history” update is completed. > > > > In several cases we’ve encountered, “bash” got a signal (SIGHUP), which > interrupted add_history(), leaving “the_history” and “history_length” > inconsistent. In the signal handling path, it tried to access “the_history” > in history_do_write() in histfile.c, which tried to de-reference a NULL > pointer. Thanks for the report. This looks like a good fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash tests failing when compiled with --enable-xpg-echo-default=yes
On 12/4/16 8:38 AM, Vladimir Marek wrote: >>> And second patch we use because of xpg-echo. Would it have sense to have >>> it included, or maybe stop the tests completely instead? >> >> You could just have turned off the xpg_echo option instead of going through >> a convoluted test (which just emulates `shopt -q') to determine whether or >> not it's on, but it does need to be off. > > Understood. I'm thinking about it this way - we have nonstandard shell > for historic reasons. Many tests from the test suite still works fine. I > want to test as much as possible of the shell Solaris people will be > using. If I just disable xpg_echo, I won't be testing that. The pain of > maintaining the tests is price for that. Sure, I understand that, and I will make reasonable changes to accommodate echo/echo -E. However, you didn't do that here. I'm ok with making the change to just turn off xpg_echo in this file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Another little patch I would like to put upstream
On 04 Dec 2016 22:53, Vladimir Marek wrote: > Studio compiler may use things like '-xregs=no%frameptr' for example. > > Thank you > -- > Vlad > # Our compiler flags contain percent sign which get mixed up with percent sign > # seprators used by sed. > > # Submitted to bug-bash@gnu.org > > --- Makefile.in 2014-01-25 13:27:30.0 -0800 > +++ Makefile.in 2015-04-02 11:18:58.143893640 -0700 > @@ -584,10 +585,10 @@ > @echo > > bashbug: $(SUPPORT_SRC)bashbug.sh config.h Makefile $(VERSPROG) > - @sed -e "s%!MACHINE!%$(Machine)%" -e "s%!OS!%$(OS)%" \ > - -e "s%!CFLAGS!%$(CCFLAGS)%" -e "s%!CC!%$(CC)%" \ > - -e "s%!RELEASE!%$(Version)%" -e "s%!PATCHLEVEL!%$(PatchLevel)%" \ > - -e "s%!MACHTYPE!%$(MACHTYPE)%" -e "s%!RELSTATUS!%$(RELSTATUS)%" \ > + @sed -e "s^!MACHINE!^$(Machine)^" -e "s^!OS!^$(OS)^" \ > + -e "s^!CFLAGS!^$(CCFLAGS)^" -e "s^!CC!^$(CC)^" \ > + -e "s^!RELEASE!^$(Version)^" -e "s^!PATCHLEVEL!^$(PatchLevel)^" \ > + -e "s^!MACHTYPE!^$(MACHTYPE)^" -e "s^!RELSTATUS!^$(RELSTATUS)^" \ >$(SUPPORT_SRC)bashbug.sh > $@ > @chmod a+rx bashbug using ^ as an anchor doesn't seem that much better than % autoconf uses & and |, but they tend to do it for vars where it's unlikely those will show up (like path vars) how about something like: @s=$$(printf '\001'); \ sed -e "s$$s!MACHINE!$$s$(Machine)$$s" ... -mike signature.asc Description: Digital signature
