When logging in, the following fails if put in $HOME/.bash_profile:
ionice -c 2 -n 0 -p `pidof bash`
... I'm guessing, because bash hasn't started yet?
--
Roger
http://rogerx.freeshell.org/
On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote:
>On Sun, Nov 21, 2010 at 04:08:33PM -0900, Roger wrote:
>> When logging in, the following fails if put in $HOME/.bash_profile:
>>
>> ionice -c 2 -n 0 -p `pidof bash`
>>
>> ... I'm guessing,
On Mon, Nov 22, 2010 at 11:58:25AM -0500, Greg Wooledge wrote:
>On Mon, Nov 22, 2010 at 07:41:48AM -0900, Roger wrote:
>> On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote:
>> >> ionice -c 2 -n 0 -p `pidof bash`
>> >If you want the PID of the current
On Mon, Nov 22, 2010 at 04:58:46PM -0500, Greg Wooledge wrote:
>On Mon, Nov 22, 2010 at 12:44:54PM -0900, Roger wrote:
>> ionice -c 2 -n 0 -p `echo $$`
>
>You don't need echo or `` here.
>
>ionice -c 2 -n 0 -p $$
Just so used to using quotes in bash, just assumed
p-shells/bash-completion-1.2
=app-shells/gentoo-bashcomp-20101217
Using both rxvt-unicode and framebuffer console.
Grepping around, I can see no references to anything color related when dealing
with compgen or $COMPREPLY. I did trace the "ls" (core-utils) to
"/usr/share/bash-compl
> On Sat, Feb 05, 2011 at 01:58:39PM -0600, Dennis Williamson wrote:
>On Sat, Feb 5, 2011 at 1:35 PM, Roger wrote:
>> When using bash completion on files within local folder, ie. "$ ls f"
>> showing results for files starting with char "f" -- or any char(
checking dependecies.\n\n"
}
# MAIN
_check_depends
_debug echo "TEST for kicks"
_debug printf "TEST for kicks\n"
---end snip---
--
Roger
http://rogerx.freeshell.org/
> On Mon, Aug 08, 2011 at 08:56:36AM -0500, Dennis Williamson wrote:
>On Mon, Aug 8, 2011 at 3:47 AM, Roger wrote:
>> I'm doing some research for one of my scripts and always liked the C style
>> ifdef inline debug statements.
...
>Another way to write the _debug(
ply above was very helpful and might provide people searching for
"ifdef style debugging" for Bash further info on inline debugging techniques.
The above does complete the task of inline ifdef style debugging, however, I
think it might confuse or slight hinder readability for som
- but really are used within
scripts.
As far as system resources, I've heard functions are quicker. But I don't know
if this is accurate as functions usually contain more execution statements!
---
--
Roger
http://rogerx.freeshell.org/
th "ifdef C style statements", maybe it's something that
can be improved upon later within Bash code?
--
Roger
http://rogerx.freeshell.org/
> On Mon, Aug 08, 2011 at 07:52:38PM -0700, Linda Walsh wrote:
...
> Nah, that's too much like right!
... sorry, I try. :-/
--
Roger
http://rogerx.freeshell.org/
ple command, Mr.
Williamson's example should be faster because it omits Mr. Orr's additional
'else' command.
(Did I trace and add-up CPU cycles correctly?)
--
Roger
http://rogerx.freeshell.org/
/then statements, etc...
Tracing your suggestion, again, functions are read in each time the script is
run
even if debug=0, wasting CPU cycles & memory. (Please correct me if I'm wrong
here.)
Think the previous one or two examples did seem to closely as possible
mimic/copy
ifdef style.
The link looks interesting though, think I'll check it out!
--
Roger
http://rogerx.freeshell.org/
brief details.
(It would be grueling to have to reread a beginner entry book on Bash to just
learn 4.0 feature additions.)
--
Roger
http://rogerx.freeshell.org/
signature.asc
Description: Digital signature
> On Thu, Aug 11, 2011 at 03:48:51AM -0800, Roger wrote:
>Great website (http://wiki.bash-hackers.org) explaining the changes in bash-4.*
>along with all other versions. (The web pages also note it's not a full list
>of
>changes.)
>
>In the past, I've scanned
quot; after the first reading.
Guess I could put a little "reminder comment" when I use collapsible functions
to remind me of this effect, as well as others reading/tracing the script.
--
Roger
http://rogerx.freeshell.org/
-ne "\033[0;31m$RET\033[0m :-(\n"; fi;
echo -ne "\n"'
PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
Gives the following return value (w/ smiley) separated by a few blank lines.
(Ref. ArchLinux Wiki, but mine is better by adding a few additio
Within GNU Screen session & VTE:
roger@localhost2 ~ $ bash
0 ;-)
roger@localhost2 ~ $ ps -ax |tail
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
30840 pts/6Ss 0:00 /bin/bash - /home/roger/bin/bashnoprofile_ionice.sh
30842 pts/5S+
Ah! That was it, SHLVL.
> On Mon, Aug 29, 2011 at 07:52:33PM -0500, Dennis Williamson wrote:
>By the way, you might find
>
>ps fx
>
>to be more useful in this case.
--
Roger
http://rogerx.freeshell.org/
_ has
mail!"'
bash-4.2_p10 doesn't say much more about $_. Learning the Bash Shell 3rd
version just paraphrases the above.
Thought I saw something more written about the $_ someplace, guess not though.
--
Roger
http://rogerx.freeshell.org/
here "$ eselect bashcomp list |grep coreutils". Just to
verify, I just wiped $HOME/.bash_completion.d/ and renabled everything and
still no completion using /bin/ls.)
--
Roger
http://rogerx.freeshell.org/
> On Mon, Sep 05, 2011 at 12:40:02AM -0800, Roger wrote:
>>The option works, as far as I can see.
>>"ls $HOM" completes to "ls $HOME " instead of "ls $HOME/", though.
>
>
>Weird.
>
>On Gentoo here, "echo $HO" does complete to
> On Mon, Sep 05, 2011 at 02:59:20AM -0800, Roger wrote:
>> On Mon, Sep 05, 2011 at 12:40:02AM -0800, Roger wrote:
>>>The option works, as far as I can see.
>>>"ls $HOM" completes to "ls $HOME " instead of "ls $HOME/", though.
>>
>
0755 ${piddir} || return 1
fi
---
Roger
http://rogerx.freeshell.org/
t post my corrections here?
--
Roger
http://rogerx.freeshell.org/
hack, I created halt scripts for each of my hosts for halting
remotely, but prior to issuing the halt command, I would send each bash process
an exit signal -- hence, saving the history.)
--
Roger
http://rogerx.freeshell.org/
> On Mon, Sep 12, 2011 at 08:36:07AM -0400, Greg Wooledge wrote:
>On Sun, Sep 11, 2011 at 11:23:48PM -0800, Roger wrote:
>> When using GNU Screen (or other terminal multiplexer), I noticed the terminal
>> multiplexer never gives each bash shell opened, a chance to write the histo
frowned upon, matter of fact think they're encouraged. Google
semi-colon usage. Semi-colons are used where a lot of commas are used, such a
lists. You can replace the major comma with a semi-colon or place a semi-colon
any where a longer pause is needed compared to a regular pause instated by a
comma.)
Fix: "The return status is 0; unless local is used outside a function, an
invalid name is supplied, or name is a readonly variable."
Additional Comment: A lot more can be done with this sentence, but over all I
just fixed the "one too many comments" by replacing one with a semi-colon.
Didn't feel like over-writing the original author's style, the semi-colons
preserve his/her style. ;-)
---
--
Roger
http://rogerx.freeshell.org/
; ${size}
As such, no newline is printed to stdout. If I omit the "eval" command and
just use ${@} (or $"@", "$@", ...) by itself, then the printf interprets the
newline escape (ie. '\n') just fine.
--
Roger
http://rogerx.freeshell.org/
st available sources with
latest available patches:
=app-shells/bash-4.2_p10
=sys-libs/readline6.2_p1
--
Roger
http://rogerx.freeshell.org/
for seconds,
-p for units of 512-byte blocks and -T -b -n -u for unscaled values.
(... think this last "Fixed Sentence" suggestion is the best.)
---
OK. That does it. I've read the whole current Bash Manual Page! If it were not
for this E-Ink technology, I likely would never have read this entire Manual.
A long read, but kind of necessary for how much scripting I do.
One last correction, I noticed a *lot* of double spacing within the manual,
especially within the SHELL BUILTIN COMMANDS type command.
---
Roger
http://rogerx.freeshell.org/
Oops. Sorry, I completely read around the specified thread initially!
--
Roger
http://rogerx.freeshell.org/
or so lines... which I'll likely start doing now. ;-)
... or did I miss something?
--
Roger
http://rogerx.freeshell.org/
signature.asc
Description: Digital signature
Hi fellow Gentooer.
> On Mon, Sep 19, 2011 at 01:37:22AM -0400, Mike Frysinger wrote:
>On Monday, September 19, 2011 01:18:02 Roger wrote:
>> I'm stumped on this as my history is in the format of:
>>
>> $ tail ~/.bash_history
>> #1316296633
>> man bash
> On Mon, Sep 19, 2011 at 08:38:44AM -0400, Greg Wooledge wrote:
>On Sun, Sep 18, 2011 at 10:11:17PM -0800, Roger wrote:
>> > On Mon, Sep 19, 2011 at 01:37:22AM -0400, Mike Frysinger wrote:
>> >On Monday, September 19, 2011 01:18:02 Roger wrote:
>> >> I'
fo!
(Started reading the GNU GAWK manual last night and now have a good jump start
on GAWK, along with incorporating regex.)
--
Roger
http://rogerx.freeshell.org/
aybe some references to the above manual pages or are we
talking severe conflict of interest? At the very least, one or two common Bash
Parameter examples would be nice!
--
Roger
http://rogerx.freeshell.org/
en you quote the string on the right hand side of =~ it changes to a
>simple string match instead of a regex match. It is sometimes
>difficult to specify a regex literally (and unquoted), so it's best to
>use a variable as shown in Steven's reply to you.
>
I believe the Bash Manual also strongly suggests, using variables for matching
as well. ;-)
--
Roger
http://rogerx.freeshell.org/
> On Tue, Sep 27, 2011 at 08:15:09AM -0400, Greg Wooledge wrote:
>On Mon, Sep 26, 2011 at 07:06:30PM -0800, Roger wrote:
>> Some good reading I found is under the Bash Manual Page section "Parameter
>> Expansion".
>>
>> From here, to learn more about r
> On Tue, Sep 27, 2011 at 07:58:50PM -0500, Peng Yu wrote:
>On Tue, Sep 27, 2011 at 6:51 PM, Chet Ramey wrote:
>> On 9/27/11 6:41 PM, Roger wrote:
>>
>>> Correct. After reading the entire Bash Manual page, I didn't see much
>>> mention
>>>
g the reader to try to ascertain, is the description really within
regex(3), or is it a little deeper such as regex(7)? On initial inspection of
regex(3) by a beginner, they're going to be overwhelmed as regex(3) deals
entirely with the C programming language! A non-programmer will just fail at
locating regex(7) as they'll be too overwhelmed. A programmer might realize
the regex(3) isn't a real description and will kind of know that they're
misled and should/might look at regex(7).
Many entry level programmers likely use Bash, before moving on to C/C++, etc.
--
Roger
http://rogerx.freeshell.org/
> On Fri, Sep 30, 2011 at 06:20:32AM +, Stephane CHAZELAS wrote:
>2011-09-29, 13:52(-08), Roger:
>[...]
>> Since you're saying the regex description is found within either regex(3) or
>> regex(7), couldn't there be a brief note within the Bash Manual Page be
ovement mode or AKA command mode.
Any ideas? I'm all Googled-out over this one.
--
Roger
http://rogerx.freeshell.org/
> On Wed, Jan 18, 2012 at 09:58:18PM -0900, Roger wrote:
>I use vi mode for Bash's realine and want to remap the ESC key to double 'ii'
>and ';;' instead of having to remove my hands from the keyboard to tap the ESC
>key.
>
>From what I see, I would be
pting the single char and awaiting a secondary char
to determine if it's a double 'i' key press. I would need to type 'i' and then
right cursor to successfully fix the typing error.
(Or, to be lazy and humorous, I could just fix it to 'silt' preventing less
finger movement.)
--
Roger
http://rogerx.freeshell.org/
ng else is
typed.
Readline doesn't time-out after the initial detection.
To me, this would be a simple code snippet insertion, but I wouldn't know where
to begin. :-/
--
Roger
http://rogerx.freeshell.org/
> On Sun, Jan 22, 2012 at 04:52:06PM -0500, Chet Ramey wrote:
>On 1/22/12 7:35 AM, Roger wrote:
>>> On Sat, Jan 21, 2012 at 09:17:32PM -0500, Chet Ramey wrote:
>>>
>>> I could look at putting in some sort of inter-character timeout, but I
>>> don't kn
> On Mon, Jan 23, 2012 at 04:52:17AM -0900, Roger wrote:
>> On Sun, Jan 22, 2012 at 04:52:06PM -0500, Chet Ramey wrote:
>>On 1/22/12 7:35 AM, Roger wrote:
>>>> On Sat, Jan 21, 2012 at 09:17:32PM -0500, Chet Ramey wrote:
>>>>
>>>> I could look at p
>In Vim, I have set the timeout to 200 milliseconds rather than the
>default 1000 (one whole second).
>
>This amounts to a typing speed of c. 5 characters per second or 60 wpm,
>a reasonable goal for the average typist.
ditto. about half the default is much better.
understand a word, they usually define it first before
assuming something as such.
Basically, hex uses numbers and a-f letters. Octal uses only numbers. (Took
me awhile before I understood octal.)
--
Roger
http://rogerx.freeshell.org/
Statements here
printf "Pres CTRL+C to stop... %s\n" ${i}
sleep 1
let "i++"
done
--
Roger
http://rogerx.sdf.org/
signature.asc
Description: Digital signature
f pounding
"CTRL-C" on your keyboard!
As far as the design/intigration of the trap within a loop, I'm guessing my
initial post contained the most simplistic, readable, proper form of a trap for
creating a safe quick exiting loop?
--
Roger
http://rogerx.sdf.org/
signature.asc
Description: Digital signature
then prefixing with "MY_" eats up
three more chars I could have used for describing my variable better.
Shrugs...
--
Roger
http://rogerx.sdf.org/
signature.asc
Description: Digital signature
me.
A trap calling kill inside of a trap.
I'm thinking, put "trap INT; kill -INT $$" inside of it's own function, named
something like exit_recurs_loop, so the first line reads "trap exit_recurs_loop
INT"
I'll put these additional trap ideas into practice h
ular Hit)
https://github.com/icy/bash-coding-style
Seems to be a duplicate of Google's style guide.
--
Roger
http://rogerx.sdf.org/
signature.asc
Description: Digital signature
>Yeah, that's pretty common.
>
>sigint_handler() {
>trap - INT
>kill -INT $$
>}
>trap sigint_handler INT
>
Extremely much more readable! My effort at readability was seemingly five
steps behind your example here.
--
Roger
http://rogerx.sdf.org/
ty larger or corporate
related scripts. "command local", likely far fewer.
"Linux Shell Scripting with Bash." (Burtch) suggested using declare instead of
local, due to local lacking the other switches declare provides. p262 (eg.
declare can specify type of variable, such as integar only.)
Between these two books, I prefer Burtch'ss book for strongly condoning
readable and writing good fall back code. (Fallback code gets quite lengthy
though.) Cameron's book is loaded with information. Both are good reads.
So in a nutshell, likely best to use "declare" within functions, although local
is quicker and explicitly read as local.
--
Roger
http://rogerx.sdf.org/
or yourself.
I find I have to insert "trap sigint_handler INT" within my loop (for/while)
section of code, for the trap to work. In my eyes or for me, this works as
expected.
--
Roger
http://rogerx.sdf.org/
> On Wed, Jan 29, 2020 at 02:24:11PM -0500, Chet Ramey wrote:
>On 1/29/20 2:05 PM, Roger wrote:
>
>> "Linux Shell Scripting with Bash." (Burtch) suggested using declare instead
>> of
>> local, due to local lacking the other switches declare provides. p262
ting looks like C, the easier it is to read.
The can push me away from defining my variables in all capitol letters. They
can even push me to code in C and Assembly, but just don't push me to script in
Python.
--
Roger
http://rogerx.sdf.org/
iables
become extremely identifiable and comprehensible.
Not so much with underscore prefix, however I'll try learning.
--
Roger
http://rogerx.sdf.org/
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname out
cd tmp ; date ; cd ..
MY LOCAL tmp/date SCRIPT
$
$ PATH=.:/bin
$ command -p date
Sun 31 Oct 2021 11:59:50 AM EDT
$ hash -l
builtin hash -p /bin/date date
$ cd tmp ; date ; cd ..
Sun 31 Oct 2021 12:00:03 PM EDT
$
On Sat, Oct 30, 2021 at 1:53 PM Chet Ramey wrote:
>
> On 10/29/21 6:06 PM, Rog
64 matches
Mail list logo
