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.eduhttp://tiswww.cwru.edu/
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.
>
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.
This
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
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 if it is
art[1]}" "${part[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.
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 folder.
>
> Seriously,
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"
print
.txt' |\
egrep '^\./[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.
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 rememb
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 "mo
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-???
> ) $(basenam
On Fri, Dec 18, 2015 at 7:05 PM, Krem 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.
>
> Assume the main folde
gt; while read i;do echo -e "${PWD
> ##*/
> } $(dirname ${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
e 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 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 &q
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 m
On Fri, Dec 18, 2015 at 7:05 PM, Krem 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.
>
> Assume the main folde
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
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.
B
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 b
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 alread
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 wh
-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
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?
--
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 b
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?
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 a
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
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
> l
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?
> I'm ha
On Wed, 2015-03-25 at 15:09 -0400, Chet Ramey wrote:
> > I'm having bash4.3 with patches up to including 33. And this time I
> > looked whether Debian added any of it's goodness ;-)
> I'll take a look.
Thanks :)
Speaking of feature-requests and history...
There is the lithist thingy, to preserv
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.
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
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
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.
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/
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 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
On Mon, Aug 29, 2011 at 7:24 PM, Roger 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 - /home/roger/bin/b
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 --nopro
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 ch
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
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 expec
wn-linux-gnu
Bash Version: 4.1
Patch Level: 2
Release Status: release
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
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
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+: synta
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 eva
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++))
>
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
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 sta
wn-linux-gnu
Bash Version: 4.1
Patch Level: 2
Release Status: release
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:
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' -DLOCALEDIR='/usr/share/locale'
51 matches
Mail list logo
