Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"
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 storage. > > > > You need a file descriptor for your memory storage. > --- > Why? Because that's what the input command expects: your HERE-string *when it reads its standard input* (fd 0) You could implement it with pipes, but as you would need a thread to write the partially-read string, just using a file is simpler. And as you can write it into a deleted file, the effect on storage should be minimal. You should however be able to translate “foo << read out <<<$(declare -p "$var" ) > while ... done <<<"$(get_net_IFnames_hwaddrs)" When it looks simpler to write the non-here version: > declare -p "$var" | read out > get_net_IFnames_hwaddrs | while ... Regards
Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"
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 set shell variables, then it will have > the same problem (and the same possible workaround). You are right. Turns out I didn't reset the variable between tests. Or you can put the inside-code into brackets :)
Special parameter $_ expands to a relative path
Hello, The Bash Reference Manual (http://www.gnu.org/s/bash/manual/bash.html#Special-Parameters) says: At shell startup, [$_ is] set to the absolute pathname used to invoke the shell or shell script being executed as passed in the environment or argument list. [...] However, with GNU bash, version 3.2.39 a simple script (named 'a'): #!/bin/bash echo "$_" prints './a' when invoked as './a'. According to the above excerpt, should it not print an absolute path to 'a' instead? Regards, Angel Tsankov
Re: Special parameter $_ expands to a relative path
On 09/01/11 15:11, Greg Wooledge wrote: On Thu, Sep 01, 2011 at 01:15:34AM -0800, Roger wrote: [...] The original poster may be interested in this page: http://mywiki.wooledge.org/BashFAQ/028 -- How do I determine the location of my script? I want to read some config files from the same place. That sounds like what he was hoping to accomplish. He is going to be disappointed, unless he's willing to accept one of the "90% solutions" that are so incredibly popular. Thanks for your answer! As I'm not inclined to accept less than 100% of anything, I'm indeed very unhappy with this situation. It turns out that a universal solution is to design shell scripts so that they never need to know their location. This, in turn, may lead to design restrictions in other parts of a system based at least partly on shell scripts. And this, at times, is certainly a pain in the ass. Regards, Angel Tsankov
No tilde expansion right after a quotation
Hi, Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of /root. Is this the expected behaviour? Angel Tsankov
Re: No tilde expansion right after a quotation
Chet Ramey wrote:
> Angel Tsankov wrote:
>> Hi,
>>
>> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of
>> /root. Is this the expected behaviour?
>
> Yes. The tilde is not the first character in the word. Portions of
> words to be tilde-expanded can't be quoted at all, either.
I see. I came to this example from a real-world problem and, in case
someone can help, here it is. I'd like to append a path to CPATH
(separating it from the current contents of CPATH with a colon only if CPATH
is set and is not empty). The path-to-append points under usr1's home
directory. Also this should work in contexts such as CPATH=... . I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
expansions just to be on the safe side, though I think home directories may
not contain spaces.) Of course, this did not work for the reason pointed
above. However, removing the quotes still does not make the
tilde-expression to expand. How can I achieve my goal?
Regards,
Angel Tsankov
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> There may be other ways to do this, but:
>
> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>
> should work.
Well, I'd like to avoid the use of external commands.
--Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 9:26 AM, Angel Tsankov
> wrote:
>> Jon Seymour wrote:
>>> There may be other ways to do this, but:
>>>
>>> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>>>
>>> should work.
>>
>> Well, I'd like to avoid the use of external commands.
>>
>
> echo is a builtin, so if you are worried about performance costs
> associated with its execution, you shouldn't be.
In fact, I'm more concerned that in the expression:
CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)" some-command
I have no way to check echo's exit status. While it is probably true that
echo will hardly ever fail, I just want to make sure my script works as I
expect it to. This means handling every possible error.
-Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> If you are willing to trade conciseness in order to eliminate use of
> builtin commands, you can use.
>
> local tmp=~usr1/blah/blah
> CPATH="${CPATH}${CPATH:+:}${tmp}"
>
> However, if you are concerned about echo failing, then you also need
> to be concerned about local failing.
>
> Hence:
>
> local tmp=~usr1/blah/bah
> [ $? -eq 0 ] || ... do something
> CPATH="${CPATH}${CPATH:+:}${tmp}"
>
> However, that is taking defensive programming to absurd levels.
>
> If the builtin echo fails it will be because the bash interpreter has
> suffered a catastrophic failure of some kind [ e.g. run out of memory
> ]. Once that has happened, all bets are off anyway.
>
> To be honest, it seems to me that your reluctance to use $(echo
> ~usr1/blah/blah) is rooted in an aesthetic objection or perhaps a lack
> of familiarity with the command substitution idiom. If the latter, I'd
> encourage you to reconsider, since command substitution is one of
> bash's most powerful features.
>
> [ Of course, others more experienced with bash idioms may object to
> $(echo ~usr1/blah/blah) on aesthetic grounds too - I welcome any
> suggested improvement!. ]
>
> jon.
Thanks for your replies,
Angel Tsankov
Re: No tilde expansion right after a quotation
Paul Jarc wrote:
> Jon Seymour wrote:
>> If the builtin echo fails it will be because the bash interpreter has
>> suffered a catastrophic failure of some kind [ e.g. run out of memory
>> ]. Once that has happened, all bets are off anyway.
>
> Probably true, but command substitution forks a separate process, so
> that can fail for reasons external to the bash process.
If process creation fails will $? will be set accordingly :-)
> Here's another possibility:
> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
That's clever!
-Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>> Jon Seymour wrote:
>>> If the builtin echo fails it will be because the bash interpreter
>>> has suffered a catastrophic failure of some kind [ e.g. run out of
>>> memory ]. Once that has happened, all bets are off anyway.
>>
>> Probably true, but command substitution forks a separate process, so
>> that can fail for reasons external to the bash process.
>>
>> Here's another possibility:
>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>
> Paul,
>
> Out of interest, how does one derive that outcome from the documented
> behaviour of bash? That is, which expansion rules are being invoked?
${#+~usr1/blah/blah} probably refers to $#. Strangely, this variable seems
to be defined even when not executing any function. However, in this case
"echo $#" prints "$#"! The expansion rules are exactly two:
${parameter:+word}
(http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameters,
3.5.3 Shell Parameter Expansion) and ${parameter} (3.5.3 Shell Parameter
Expansion)
-Angel
Re: No tilde expansion right after a quotation
Paul Jarc wrote:
> Jon Seymour wrote:
>> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>> Out of interest, how does one derive that outcome from the documented
>> behaviour of bash? That is, which expansion rules are being invoked?
>
> It's ${parameter+word}, using $# (which is always set) as the
> parameter.
How do you know that $# is always set? And what about $...@? To what values
are these parameters set outside any function?
A more appropriate parameter to use could be $? which, by pure logic, seems
to be at least as often set as is $#.
-Angel
Re: No tilde expansion right after a quotation
Eric Blake wrote:
> According to Angel Tsankov on 2/15/2009 3:02 PM:
>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>> expansions just to be on the safe side, though I think home
>> directories may not contain spaces.)
>
> There are some contexts, such as variable assignments, where double
> quotes are not necessary.
>
> foo='a b'
> bar=$foo
>
> is just as safe as
>
> bar="$foo"
>
> In fact, it is MORE portable to avoid double quotes in assignments,
> if you are worried about writing scripts portable to more than just
> bash. Of these two constructs:
>
> foo="`echo "a b"`"
> bar=`echo "a b"`
>
> only the setting of bar is guaranteed to parse correctly in all
> shells.
Eric, thanks for youy replay. If double quotes are not that portable, then
how am I suppose to assign the output from some command to a variable when
the output contains a space?
-Angel
Re: No tilde expansion right after a quotation
Dave B wrote: > Angel Tsankov wrote: >> Eric, thanks for youy replay. If double quotes are not that >> portable, then how am I suppose to assign the output from some >> command to a variable when the output contains a space? > > Word splitting doesn't happen on assignments, so: > > $ var=$(echo "foo bar baz") > $ echo "$var" > foo bar baz Hmm, thanks for pointing this out. -Angel
Passing paths with spaces from one command to another
Hello, I want to pass the output from one command (e.g. find) to some other command so that each path (output by the first command) gets into a distinct positional parameter of the second command. How can I do this if some paths contain spaces?
Re: Passing paths with spaces from one command to another
What if the second command is a function defiend in a shell script, or a bash built-in command?
IFS valid characters
Hi, What are the valid charactes for the IFS variable? In particular, is '\0' a valid one?
Program to search unusual strings?
Hi, Which program can be used to search for line-feed characters in a string that might contain null characters? Regards, Angel Tsankov
Creating directories with sticky bit set
Hello, What can I do so that every directory I create has the sticky bit set? Regards, Angel Tsankov
Re: Creating directories with sticky bit set
Greg Wooledge wrote:
> If you only ever create directories from interactive shells with
> the "mkdir" command, you could override it with a function:
>
> mkdir() {
> command mkdir "$@" &&
> chmod +t "$@"
> }
>
> (In reality you'd want to process function arguments, and remove for
> example a "-p" option before passing them along to chmod. I'll leave
> that part as an exercise.)
>
Let's say that removing '-p' is straightforward, but what about setting the
sticky bit to every newly created directory component?
Regards,
Angel Tsankov
Testing standard output and exit statuses from commands in a pipe
Hello! I'd like to pipe the output from a command, say A, to another command, say B, then check if both commands completed successfully (i.e.with exist status 0) and, if so, compare the standard output from command B to some string. How can I do this in a bash script? Regards, Angel Tsankov
Professional Grant writing workshop (University of Illinois, Chicago)
The Grant Institute's Grants 101: Professional Grant Proposal Writing Workshop will be held at the University of Illinois, Chicago, April 18-20, 2005. Interested development professionals, researchers, faculty, and graduate students should register as soon as possible, as demand means that seats will fill up quickly. Please forward, post, and distribute this e-mail to your colleagues and listservs. All participants will receive certification in professional grant writing from the Institute. For more information call (888) 824 - 4424 or visit The Grant Institute website at http://www.thegrantinstitute.com. Please find the program description below: THE GRANT INSTITUTE GRANTS 101: Professional Grant Proposal Writing Workshop held at University of Illinois Chicago, Illinois Chicago Illinois Union Room 218 April 18-20, 2005 8:00 AM - 5:00 PM The Grant Institute's Grants 101 Course is an intensive and detailed introduction to the process, structure, and skill of professional proposal writing. This course is characterized by its ability to act as a thorough overview, introduction, and refresher at the same time. In this course, participants will learn the entire proposal writing process and complete the course with a solid understanding of not only the ideal proposal structure, but a holistic understanding of the essential factors, which determine whether or not a program gets funded. Through the completion of interactive exercises and activities, participants will complement expert lectures by putting proven techniques into practice. This course is designed for both the beginner looking for a thorough introduction and the intermediate looking for a refresher course that will strengthen their grant acquisition skills. This class, simply put, is designed to get results by creating professional grant proposal writers. Participants will become competent program planning and proposal writing professionals after successful completion of the Grants 101 course. In three active and informative days, students will be exposed to the art of successful grant writing practices, and led on a journey that ends with a masterful grant proposal. Grants 101 consists of three (3) courses that will be completed during the three-day workshop. FUNDAMENTALS OF PROGRAM PLANNING This course is centered on the belief that "it's all about the program." This intensive course will teach professional program development essentials and program evaluation. While most grant writing "workshops" treat program development and evaluation as separate from the writing of a proposal, this class will teach students the relationship between overall program planning and grant writing. PROFESSIONAL GRANT WRITING Designed for both the novice and experienced grant writer, this course will make each student an overall proposal writing specialist. In addition to teaching the basic components of a grant proposal, successful approaches, and the do's and don'ts of grant writing, this course is infused with expert principles that will lead to a mastery of the process. Strategy resides at the forefront of this course's intent to illustrate grant writing as an integrated, multidimensional, and dynamic endeavor. Each student will learn to stop writing the grant and to start writing the story. Ultimately, this class will illustrate how each component of the grant proposal represents an opportunity to use proven techniques for generating support. GRANT RESEARCH At its foundation, this course will address the basics of foundation, corporation, and government grant research. However, this course will teach a strategic funding research approach that encourages students to see research not as something they do before they write a proposal, but as an integrated part of the grant seeking process. Students will be exposed to online and database research tools, as well as publications and directories that contain information about foundation, corporation, and government grant opportunities. Focusing on funding sources and basic social science research, this course teaches students how to use research as part of a strategic grant acquisition effort. REGISTRATION $597.00 tuition includes all materials and certificates. Each student will receive: · The Grant Institute Certificate in Professional Grant writing · The Grant Institute's Guide to Successful Grant Writing · A to Z Grant Writing · The Grant Institute Grant Writer's Workbook with sample proposals, forms, and outlines REGISTRATION METHODS 1) On-Line -Visit www.thegrantinstitute.com and click on the Registration area. Fill out the online registration form completely. We'll send your confirmation by e-mail. 2) By Phone - Call toll free (888) 824 - 4424 to register by phone. Our friendly Program Coordinators will be happy to assist you and answer your questions. 3) By E-mail - Send an e-mail with your name, organization, and basic contact information to [EMAIL PROTECTED] and w
