Re: Does bash save/restore terminal settings as required by POSIX job control?
On 6/22/20 9:26 PM, Godmar Back wrote: > In any event, this was very illuminating - though I have one last > question: why did you not implement it? It's not a requirement. The text you quoted is from the rationale, and there is no corresponding text in the normative portion of the standard. It's an implementation suggestion. It's not necessary, because applications that care about such things, in the sense that they manage the screen and the terminal settings, take care of this themselves. Chet -- ``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/~chet/
problem with extra space; setting? cygwin only?
I do:
set output
echo ">$1<"
>output<
output=""printf ${1:+-v $1} "%s:%s" 23 myproc
-Bash: printf: ` output': not a valid identifier
for some reason it is regarding the space before $1 in
the printf as part of the variable name.
It doesn't seem to do this on linux (lnx 4.4.12(3), cyg-4.4.12(1)).
If I remove the space it works on both linux and cygwin.
The manpage shows [-v var], as the syntax, but [-vVAR] works in both
places. Is the manpage only correct sometimes? Or is there some switch to
toggle this behavior that I don't know about?
Thanks!
-linda
Re: problem with extra space; setting? cygwin only?
On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
> set output
> output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> -Bash: printf: ` output': not a valid identifier
Your command is simply wrong. You've got two double-quotes in a row,
which simply cancel each other out, as they contain only the empty
string. So, you are running this:
output=printf ${1:+-v $1} %s:%s 23 myproc
Or in other words, create the environment variable 'output' with content
'printf' in the temporary environment of the command "output", which is
generated by the unquoted parameter expansion between the assignment
and the %s:%s argument.
Moreover, the error message you show is *not* the one generated by this
command.
unicorn:~$ set output
unicorn:~$ output=""printf ${1:+-v $1} "%s:%s" 23 myproc
bash: -v: command not found
The unquoted parameter expansion ${1:+...} expands to the two words
"-v" and "output", so you are attempting to run a command named "-v".
Thus, the error that I showed.
Either your email does not contain the actual command you're running,
or you've misrepresented the error message it produces. Or both.
Re: [PATCH 5.1] zread: read files in 4k chunks
The 'stat(2)' system call returns an optimal i/o size for files since some files in addition to being on disks with a 4k sector size (making 128bytes a slow choice for reads, and a real slow choice for writes), also can be on a RAID with it's own optimal i/o size. I think the 'stat(1)' prog shows the same value with "%o": "stat -c%o" . 65536 On Mon, Jun 22, 2020 at 1:19 PM Jason A. Donenfeld wrote: > On Mon, Jun 22, 2020 at 2:16 PM Ilkka Virta wrote: > > > > On 22.6. 19.35, Chet Ramey wrote: > > > On 6/22/20 1:53 AM, Jason A. Donenfeld wrote: > > >> Currently a static sized buffer is used for reading files. At the > moment > > >> it is extremely small, making parsing of large files extremely slow. > > >> Increase this to 4k for improved performance. > > > > > > I bumped it up to 1024 initially for testing. > > > > It always struck me as odd that Bash used such a small read of 128 > > bytes. Most of the GNU utils I've looked at on Debian use 8192, and a > > simple test program seems to indicate glibc's stdio reads 4096 bytes at > > one read() call. > > Plus most other shells people use... > >
Re: problem with extra space; setting? cygwin only?
there was a linefeed in my source between output="" and the printf.
It's a gmail feature to mangle your input.
On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote:
> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
> > set output
> > output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> > -Bash: printf: ` output': not a valid identifier
>
> Your command is simply wrong. You've got two double-quotes in a row,
> which simply cancel each other out, as they contain only the empty
> string. So, you are running this:
>
> output=printf ${1:+-v $1} %s:%s 23 myproc
>
> Or in other words, create the environment variable 'output' with content
> 'printf' in the temporary environment of the command "output", which is
> generated by the unquoted parameter expansion between the assignment
> and the %s:%s argument.
>
> Moreover, the error message you show is *not* the one generated by this
> command.
>
> unicorn:~$ set output
> unicorn:~$ output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> bash: -v: command not found
>
> The unquoted parameter expansion ${1:+...} expands to the two words
> "-v" and "output", so you are attempting to run a command named "-v".
> Thus, the error that I showed.
>
> Either your email does not contain the actual command you're running,
> or you've misrepresented the error message it produces. Or both.
>
>
Re: problem with extra space; setting? cygwin only?
It's a gmail feature to mangle your input in weird ways when you cut/paste.
the line with 'output=""' is separate from the "printf" line. Sorry.
On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote:
> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
> > set output
> > output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> > -Bash: printf: ` output': not a valid identifier
>
> Your command is simply wrong. You've got two double-quotes in a row,
> which simply cancel each other out, as they contain only the empty
> string. So, you are running this:
>
> output=printf ${1:+-v $1} %s:%s 23 myproc
>
> Or in other words, create the environment variable 'output' with content
> 'printf' in the temporary environment of the command "output", which is
> generated by the unquoted parameter expansion between the assignment
> and the %s:%s argument.
>
> Moreover, the error message you show is *not* the one generated by this
> command.
>
> unicorn:~$ set output
> unicorn:~$ output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> bash: -v: command not found
>
> The unquoted parameter expansion ${1:+...} expands to the two words
> "-v" and "output", so you are attempting to run a command named "-v".
> Thus, the error that I showed.
>
> Either your email does not contain the actual command you're running,
> or you've misrepresented the error message it produces. Or both.
>
>
Re: problem with extra space; setting? cygwin only?
On Tue, Jun 23, 2020 at 12:33:23PM -0700, L A Walsh wrote: > It's a gmail feature to mangle your input in weird ways when you cut/paste. > the line with 'output=""' is separate from the "printf" line. Sorry. First, stop top-quoting. Second, if you know that gmail is horrible and is going to mangle your input, stop using it. Third, if you actually want to debug the issue, you will get a MUCH better view of the variable's contents if you hex-dump it, instead of just throwing some random punctuation around it and praying that what you see on the terminal is all that's in the variable. printf %s "$output" | od -tx1 -An or something similar. Since you mentioned Cygwin, and since you mentioned gmail, one can guess that Microsoft Windows is invovled in this picture, which means that carriage returns are likely to be involved in this picture, which can mess up a script in a multitude of ways. Hex-dumping the variable's contents would be a reasonably sure way to tell whether there are carriage returns, non-breaking spaces, or other abominations in the variable. If it turns out that the variable actually *is* clean, and you've legitimately found some sort of bug that only happens in the Cygwin environment, well, congratulations. I guess. Not that many people on this list have access to that environment for confirmation purposes.
Re: problem with extra space; setting? cygwin only?
On 6/23/20 3:33 PM, L A Walsh wrote:
> On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote:
>
>> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
>>> set output
>>> output=""printf ${1:+-v $1} "%s:%s" 23 myproc
>>> -Bash: printf: ` output': not a valid identifier
>>
>> Your command is simply wrong. You've got two double-quotes in a row,
>> which simply cancel each other out, as they contain only the empty
>> string. So, you are running this:
>>
>> output=printf ${1:+-v $1} %s:%s 23 myproc
> It's a gmail feature to mangle your input in weird ways when you
> cut/paste.
> the line with 'output=""' is separate from the "printf" line. Sorry.
Why would you use their incompetent webmail if you know it is broken?
Be that as it may, I can trivially reproduce your error by destroying my
own $IFS
$ output="" IFS=/
$ set output
$ printf ${1:+-v $1} "%s:%s" 23 myproc
bash: printf: ` output': not a valid identifier
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: problem with extra space; setting? cygwin only?
On 6/23/20 3:21 PM, L A Walsh wrote:
> I do:
>
> set output
> echo ">$1<"
>> output<
> output=""printf ${1:+-v $1} "%s:%s" 23 myproc
>
>
>
> -Bash: printf: ` output': not a valid identifier
It looks like word splitting on the result of ${1:+-v $1} isn't taking
place. That might be due to IFS; or because this isn't an accurate
representation of your actual script, which includes quoting; or because
the character between the `v' and `$' isn't a space.
Chet
--
``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/~chet/
Re: problem with extra space; setting? cygwin only?
re: IFS... yup. that was it, not sure how it got cleared, but it did.
Thanks for the clue.
As for gmailnecessity creates unfortunate circumstances...having your
main file system (RAID 0) fail, along with your backups (in a separate disk
enclosure, also RAID 0), isn't something that happens every day. Still
unsure what, if anything, is recoverable.
On Tue, Jun 23, 2020 at 1:04 PM Eli Schwartz
wrote:
> Why would you use their incompetent webmail if you know it is broken?
>
>
> Be that as it may, I can trivially reproduce your error by destroying my
> own $IFS
>
> $ output="" IFS=/
> $ set output
> $ printf ${1:+-v $1} "%s:%s" 23 myproc
> bash: printf: ` output': not a valid identifier
>
>
