Re: count in vi mode alters prompt

On 5/20/24 9:34 AM, Mohamed Akram wrote: Is there a way to disable this feature, at least in vi mode? No. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu

Re: count in vi mode alters prompt

When using vi mode in bash, whenever a count is used before a command, >> bash replaces the prompt with (arg: n) where n is the count entered. >> This causes the entire line to shift, which is particularly jarring if >> a long prompt is used, as is common. >

Re: count in vi mode alters prompt

On 5/18/24 5:28 PM, mohd.ak...@outlook.com wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When using vi mode in bash, whenever a count is used before a command, bash replaces the prompt with (arg: n) where n is the count entered

count in vi mode alters prompt

Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin23.2.0 Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When using vi mode in bash, whenever a count is used before a command

[PATCH] builtin_read: count null character toward -n/-N limit

characters - both the fact that it discards them, and that the null characters (as of this patch) will count toward the -n/-N maximum. --- Notes: I earlier tried to submit a bug report using bashbug but I am not sure if it came through. Sending as a patch now. Sorry for the duplicate

Re: count

t[2]}" "${part[3]}" "$(wc -l < "$f")" done ' _ {} + _: -c: line 0: unexpected EOF while looking for matching `"' _: -c: line 1: syntax error: unexpected end of file -- View this message in context: http://gnu-bash.2382.n7.nabble.com/count-tp16675p16702.html Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: count

On Fri, Dec 18, 2015 at 7:05 PM, Krem <valk...@yahoo.com> wrote: > Hi all, > > I have one folder and this folder contains several folders. Each sub > folders > contains 5 or 6 files. So i want count the number of rows within each > file and produce an output. &g

Re: count

with a .txt or .cvs suffix. The egrep looks for directories which start with a "./" (which is what find prefixes them with) followed by a digit. Other characters after that can be anything The 3rd line is the "do" loop that actually produces output. > > the firs

Re: count

e ${i > ​ > } > ​ | cut -b 3-​ > ) $(basename ${i}) $(wc -l ${i})" ;done | cut -d " " -f 1,2,4,3 > > The find scans all direct subdirectories (1 level down only) for regular > files with a .txt or .cvs suffix. > The egrep looks for directories which start wit

Re: count

On Mon, Dec 21, 2015 at 07:58:02AM -0600, John McKown wrote: > OOPS, slight correction: > > find . -maxdepth 2 -mindepth 2 -type f -name '*.csv' -o -name '*.txt' |\ > egrep '^\./[0-9]' |\ > while read i;do echo -e "${PWD > ???##???*/ > } $(dirname ${i > ??? > } > ??? | cut -b 3-??? > )

Re: count

On Mon, Dec 21, 2015 at 08:21:04AM -0600, John McKown wrote: > find . -maxdepth 2 -mindepth 2 -type f -name '*.csv' -o -name '*.txt' |\ > egrep '^\./[0-9]' |\ > xargs awk 'ENDFILE {print FILENAME "\t" FNR;}' |\ > sed -r 's|^./||;s|/|\t|' |\ > xargs -L 1 echo -e "${PWD##*/}\t"??? > ???This is

Re: count

Thanks for the training. I appreciate people pointing out my errors, that's how I learn too. I'll blame GMAIL for the mish-mash. I don't have as good a control of it as I would like (sorry). I'm always forgetting about people who put LFs in a file name. That is just so weird, to me. I should

Re: count

'^\./[0-9]' |\ xargs awk 'ENDFILE {print FILENAME "\t" FNR;}' |\ sed -r 's|^./||;s|/|\t|' |\ xargs -L 1 echo -e "${PWD##*/}\t"??? -- View this message in context: http://gnu-bash.2382.n7.nabble.com/count-tp16675p16699.html Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: count

On Mon, Dec 21, 2015 at 08:53:55AM -0700, Krem wrote: > I tried this one, but failed if the folder has more than one file name (eg > *.csv) in that folder. Seriously, use this one: find . \( -iname '*.txt' -o -iname '*.csv' \) -exec bash -c ' for f; do IFS=/ read -ra part <<< "$f"

Re: count

I've "squirreled" that one away on GitHub, in a gist. Thanks. On Mon, Dec 21, 2015 at 11:00 AM, Greg Wooledge wrote: > On Mon, Dec 21, 2015 at 08:53:55AM -0700, Krem wrote: > > I tried this one, but failed if the folder has more than one file name > (eg > > *.csv) in that

Re: count

e file name the last column is the count Row 3 and 5 must be excluded because they don't have proper file name and also the 5th column does not start with number. I want to split the output into two files File one contains only add* and file two should contain name*. I reach to my goa

Re: count

On Fri, Dec 18, 2015 at 7:05 PM, Krem <valk...@yahoo.com> wrote: > Hi all, > > I have one folder and this folder contains several folders. Each sub > folders > contains 5 or 6 files. So i want count the number of rows within each > file and produce an output. &g

count

Hi all, I have one folder and this folder contains several folders. Each sub folders contains 5 or 6 files. So i want count the number of rows within each file and produce an output. Assume the main folder called A and it has three subfolders folder1, folder2 and folder3. Folder1 has

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/26/15 8:28 PM, Christoph Anton Mitterer wrote: So why not make a thrid mode like: - if cmdhist=on lithist=not-in-file which keeps: if true; then\n echo foo\n fi in the history but writes the serialised if true; then echo foo ; fi to the history file. Because

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/25/15 6:03 PM, Christoph Anton Mitterer wrote: On Wed, 2015-03-25 at 16:21 -0400, Chet Ramey wrote: https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html Maybe I've missed something but that thread basically just discussed the same issue without giving a solution, right?

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Thu, 2015-03-26 at 16:26 -0400, Chet Ramey wrote: And b) it seems kinda ugly that one needs to explicitly set a default value that would be set later anyway. Maybe. Okay, keep me tuned if you should plan to actually do that, cause then I can revise manually setting it :) It is what it

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Thu, 2015-03-26 at 15:21 -0400, Chet Ramey wrote: What do you mean ignore its effect? You have newlines embedded in history entries; what do you plan to do about them? Well that was just the uneducated idea based on blind assumptions by *not* having read the code O:-) AFAIU, both already

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Thu, 2015-03-26 at 16:54 -0400, Chet Ramey wrote: The solution cannot be bash-specific; the history library is used by many other applications. One, design-wise ugly, idea: Couldn't you abuse the history comment char another time for that? Like consider anything between a ^#[[:digit:]] to be

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/25/15 8:06 PM, Christoph Anton Mitterer wrote: On Wed, 2015-03-25 at 16:19 -0400, Chet Ramey wrote: When you start bash, and source your .bashrc, the history comment character is not set. You haven't set it in .bashrc, I assume Yes, I haven't. Since that's not set, the lines beginning

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 03/26/2015 01:21 PM, Chet Ramey wrote: What do you mean ignore its effect? You have newlines embedded in history entries; what do you plan to do about them? Can't history lines be recorded as $'...\n...' so as to be one line per command, even when the command contained newlines? -- Eric

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/26/15 4:51 PM, Eric Blake wrote: On 03/26/2015 01:21 PM, Chet Ramey wrote: What do you mean ignore its effect? You have newlines embedded in history entries; what do you plan to do about them? Can't history lines be recorded as

feature-request: don't count history time comment lines when in HISTFILESIZE

Hey. When HISTTIMEFORMAT is used the history time comment lines are written to HISTFILE. Therefore, HISTFILESIZE is effectively only half as large. Would it be possible to simply not count the history time comment lines when enforcing HISTFILESIZE? Cheers, Chris.

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/25/15 3:02 PM, Christoph Anton Mitterer wrote: On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote: The history file truncation code already skips lines that look like history timestamps. Look at history.c:history_truncate_file(). Ah? Hmm was that only recently introduced? Bash-3.0.

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/25/15 2:07 PM, Christoph Anton Mitterer wrote: Hey. When HISTTIMEFORMAT is used the history time comment lines are written to HISTFILE. Therefore, HISTFILESIZE is effectively only half as large. Would it be possible to simply not count the history time comment lines when enforcing

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote: The history file truncation code already skips lines that look like history timestamps. Look at history.c:history_truncate_file(). Ah? Hmm was that only recently introduced? I'm having bash4.3 with patches up to including 33. And this time I

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On 3/25/15 3:50 PM, Christoph Anton Mitterer wrote: There is the lithist thingy, to preserve newlines in commands which I'd quite like. But it doesn't work obviously when [re-]storing [from/]to the history file. Would it be possible to have e.g. another option, so that things work like

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Wed, 2015-03-25 at 16:21 -0400, Chet Ramey wrote: https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html Maybe I've missed something but that thread basically just discussed the same issue without giving a solution, right? I understand you concerns about any format changes, that's

Re: feature-request: don't count history time comment lines when in HISTFILESIZE

On Wed, 2015-03-25 at 16:19 -0400, Chet Ramey wrote: When you start bash, and source your .bashrc, the history comment character is not set. You haven't set it in .bashrc, I assume Yes, I haven't. Since that's not set, the lines beginning with `#[digit]' are not recognized as timestamps and

BASH_SUBSHELL count not counting?

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+ 0:00 bash

Re: BASH_SUBSHELL count not counting?

On Mon, Aug 29, 2011 at 7:24 PM, Roger rogerx@gmail.com wrote: 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/6    Ss     0:00 /bin/bash -

Re: BASH_SUBSHELL count not counting?

By the way, you might find ps fx to be more useful in this case. On Mon, Aug 29, 2011 at 7:24 PM, Roger rogerx@gmail.com wrote: Within GNU Screen session VTE: roger@localhost2 ~ $ bash 0 ;-) roger@localhost2 ~ $ ps -ax |tail Warning: bad ps syntax, perhaps a bogus '-'? See

Re: BASH_SUBSHELL count not counting?

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/

Re: weird behaviour of ((count++)) when using , , to change to lower case

On 8/1/10 7:05 PM, Dennis Williamson wrote: If I do the echo line twice, I get a segfault in both Bash 4.0.33(1)-release and 4.1.0(1)-release. Thanks. This will be fixed in bash-4.2. And you're right about being evaluated twice. This was already changed after bash-4.1 was released; the

weird behaviour of ((count++)) when using , , to change to lower case

Description: Incrementing a variable with ((count++)), which should access the value in the variable and then increment it by 1 has some strange behaviour. In some situations it seems to increment the variable before accessing it, and in others it increments it by 2 Repeat-By: Make an array to work

Re: weird behaviour of ((count++)) when using , , to change to lower case

Am 01.08.2010 13:06, schrieb Andrew Benton: Also good. Now try converting it to lower case with ,, andy:~$ count=0 andy:~$ echo ${days[${count}],,}, ${days[$((count++))],,}, ${days[$((count++))],,} monday, tuesday, thursday What happened to wednesday? I'd rather expect this to print monday

Re: weird behaviour of ((count++)) when using , , to change to lower case

it to lower case with ,, andy:~$ count=0 andy:~$ echo ${days[${count}],,}, ${days[$((count++))],,}, ${days[$((count++))],,} monday, tuesday, thursday What happened to wednesday? I'd rather expect this to print monday, monday, tuesday, since you left out the ++ in the first term. I think

inconsistent exit status of ((count++))

Description: [Detailed description of the problem, suggestion, or complaint.] If I use set -e to make my scripts exit on error, the scripts fail if I use something like: count=0 ((count++)) Repeat-By: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0

Re: inconsistent exit status of ((count++))

At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect of: 1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates to zero, and 2. `var

Re: inconsistent exit status of ((count++))

On 30/07/10 19:55, Stefano Lattarini wrote: At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect of: 1. `((EXPR))' returning a non-zero exit status iff EXPR

Re: inconsistent exit status of ((count++))

At Friday 30 July 2010, Andrew Benton wrote: On 30/07/10 19:55, Stefano Lattarini wrote: At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect

Re: inconsistent exit status of ((count++))

On Fri, Jul 30, 2010 at 07:33:00PM +0100, Andrew Benton wrote: On 30/07/10 19:55, Stefano Lattarini wrote: I don't think it's a bug, it's just an effect of: 1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates to zero, and That makes no sense to me. Why would evaluating

Re: inconsistent exit status of ((count++))

On Fri, Jul 30, 2010 at 09:49:22PM +0200, Stefano Lattarini wrote: But then, maybe an exit status of `2' instead of `1' in case of errors in ((...)) would be helpful -- currently the exit status is still `1' also if a real error is present: $ ((1+)); echo \$?=$? bash: ((: 1+: syntax

Re: inconsistent exit status of ((count++))

At Friday 30 July 2010, Greg Wooledge wrote: On Fri, Jul 30, 2010 at 09:49:22PM +0200, Stefano Lattarini wrote: But then, maybe an exit status of `2' instead of `1' in case of errors in ((...)) would be helpful -- currently the exit status is still `1' also if a real error is present:

fc edit gets last command count wrong

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat'