Re: ulimit -c unlimited
> Am 26.07.2017 um 03:43 schrieb 積丹尼 Dan Jacobson : > > $ ulimit -c 99 > $ ulimit -c 99 > $ ulimit -c unlimited > bash: ulimit: core file size: cannot modify limit: Operation not permitted > > Maybe say: try again with numbers, not letters. Do you get this as root too? If the hard limit is unlimited, then you can raise the soft limit again also as normal user to be unlimited. So the statement "Operation not permitted" is correct, although it means: "can't raise hard limit again" as without -S or -H it sets both limits. The soft limit OTOH can be changed between a value and unlimited as often as you like, as the long as the hard limit stays to be set to unlimited. -- Reuti
Re: No such file..?
> Am 05.05.2017 um 05:57 schrieb Peter Passchier : > > I downloaded a Solaris binary and I was wondering whether I could get it > to execute with the --version commandline argument (it worked for an > arm7 binary before). But that's not what concerns me. > > $ /home/pp/bin/caddy --version > -bash: /home/pp/bin/caddy: No such file or directory > > $ file /home/pp/bin/caddy > /home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked, interpreter /lib/amd64/ld.so.1, not stripped And the interpreter /lib/amd64/ld.so.1 exists? -- Reuti > > $ ls -AFl /home/pp/bin/caddy > -rwxr-xr-x 1 pp pp 16229894 2017-05-05 10:30 /home/pp/bin/caddy* > > I would think that is a strange response... > Peter > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Syntax error near unexpected token `newline' within loops
> Am 24.04.2017 um 14:58 schrieb Greg Wooledge :
>
> On Mon, Apr 24, 2017 at 07:49:36AM -0500, Eduardo Bustamante wrote:
>> On Mon, Apr 24, 2017 at 7:44 AM, Greg Wooledge wrote:
>> [...]
>>> The outer (( )) in the C-style for loop already create an arithmetic
>>> expression context. You don't need to use $(( )) inside them. You can
>>> simply write:
>>>
>>> for (( INDEX=0; INDEX<10-${#V_NAME};; INDEX++ ))
>>
>> I think this is just to show the bug. i.e. these two should do the same:
>>
>> dualbus@debian:~$ bash -c 'for (( ; $(($(:))); )); do :; done'
>> bash: -c: line 0: syntax error near unexpected token `newline'
>> bash: -c: line 0: `for (( ; $(($(:))); )); do :; done'
>>
>> dualbus@debian:~$ bash -c 'for (( ; $((`:`)); )); do :; done'
>
> Yeah, I'm not disputing whether there's actually a bug here, just
> pointing out that the code can be simplified to avoid it. The fact that
> no sane person should write code this way is probably why the bug went
> undiscovered for so long.
AFAICS in version 4.2.45(1) it works as expected.
-- Reuti
> Seriously, "expr length"?! In a script that is already using bashisms?
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Issus with popd and pushd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am 17.04.2017 um 20:05 schrieb Pete Smith: > The problem with: dirs, pushd, popd is that they output a single line of > paths that's difficult to parse visually quickly, especially when there are > many paths in the dir stack and the path > names are long. > > dirs offers a reasonable solution with the -v option > > Unfortunately popd and pushd do NOT offer this option. > > Using an alias solution: > > popd | sed 's/\s/\n/g' | nl > > doesn't work, probably because they are shell built-ins. It's a question whether it's a feature or a bug: if stdout is redirected for it, the directory isn't changed any longer AFAICS. - -- Reuti > I'd recommend the addition of the -v option to popd and pushd, or a fix so > that an alias like the one outline above, works. > > Appreciate your comments and feedback on this. > > -Pete -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlj1JWgACgkQo/GbGkBRnRofagCfUNXHWBVDDYoKZUS73A5+YGkp JP8An0NkPu2i5U0rI3tUcbrgXbB8sTKF =8mly -END PGP SIGNATURE-
Re: bash 4.4 null byte warning!!
> Am 10.04.2017 um 07:08 schrieb emlyn.j...@wipro.com:
>
> Hi Greg/Chet Ramey,
>
> Thank you so much for the response! It gave me an idea on what has to be
> done next.
>
> We have been using the same script all these years and had no issues of
> broken commands when used with the lower versions of bash which is why I have
> been thinking whether to rewrite the script for the new bash(4.4) or edit the
> bash source.
>
> The reason behind using –print0 is to use the resultant output to find a
> binary
>
> Below are the lines of code followed by the find command:
>
> FIND_RPM="$(find $linIdx -type d -name "${2}" -print0 2>/dev/null)"
Why using -print0 here? You can fill the $FIND_RPM variable also without it,
the \n is not part of the variable afterwards but you get one long line if more
than one entry is found (and this couldn't be used below by appending /bin).
FIND_RPM="$(find $linIdx -type d -name "${2}" -print -quit)"
if you want only the first one found. And why not searching directly for
"${2}/bin".
-- Reuti
> [ -n "$FIND_RPM" ] && \
> [ -s "${FIND_RPM}/bin" ] && \
> bdt_msg 4 "[D] Found %s in %s component area." "$2" "$linIdx" && \
> …
> …
>
> >> If you want to suppress the warning, you'll have to edit the source and
> >> rebuild.
> Do you have a guide on how to do this?
>
> Or else I have been planning to add tr to remove the nuls as suggested by
> Greg.
>
> Regards,
> Emlyn Jose.
>
> -
> -Original
> Message---
> From: Chet Ramey [mailto:chet.ra...@case.edu]
> Sent: Saturday, April 8, 2017 7:48 AM
> To: Emlyn Jose (GIS); bug-bash@gnu.org
> Cc: chet.ra...@case.edu
> Subject: Re: bash 4.4 null byte warning!!
>
> On 4/6/17 3:47 AM, emlyn.j...@wipro.com wrote:
> > Hi,
> >
> >
> >
> > We are trying to use the bash 4.4 downloaded from
> > http://ftp.gnu.org/gnu/bash/ on our RHEL 6.2 machine.
> >
> > But while using a script that has this command :
> >
> > FIND_RPM=`find /opt/RPM/components -type d -name enum-1.1.6-print0`
> >
> > It throws a warning as below:
> >
> > bash:warning:command substitution:ignored null byte ininput
>
> Yes. It drops the null bytes because C strings can't handle them. I
> received bug reports asking why bash silently transforms the command
> substitution output and added the warning while not changing the behavior.
>
> If you want to suppress the warning, you'll have to edit the source and
> rebuild.
>
> This does beg the question of why you're using -print0 without something on
> the receiving end to handle the null bytes.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
>
>
>
> -Original
> Message--
> From: Greg Wooledge [mailto:wool...@eeg.ccf.org]
> Sent: Thursday, April 6, 2017 8:15 PM
> To: Emlyn Jose (GIS)
> Cc: bug-bash@gnu.org
> Subject: Re: bash 4.4 null byte warning!!
>
> On Thu, Apr 06, 2017 at 07:47:35AM +, emlyn.j...@wipro.com wrote:
> > FIND_RPM=`find /opt/RPM/components -type d -name enum-1.1.6 -print0`
> > It throws a warning as below:
> >
> > bash: warning: command substitution: ignored null byte in input
>
> Your command is broken, and bash is warning you of this. Why do you want to
> silence the warning instead of fixing the command?
>
> If your find returns a single result, you get a filename followed by NUL, and
> the NUL is discarded, leaving you a filename inside the command substitution
> (and therefore the variable). You could achieve the EXACT same result by
> dropping the -print0. Then, if you get a single result from find, you get
> the filename followed by newline, and the command substitution discards the
> trailing newline, leaving you just the filename in the command substitution
> and therefore the variable.
>
> On the other hand, if your find command returns MULTIPLE results, then you
> have file1\000file2\00
Re: Symlinks handled inconsistently by cd and wild card expansion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.03.2017 um 20:06 schrieb Chet Ramey: > On 3/30/17 11:55 AM, Reuti wrote: > >> There are the options -P and -L to `pwd` and `cd`, i.e. and `cd -P ..` >> follows the path up, independent from the symlink, while the default is -L. >> >> I don't think that changing it in general would be good, but agree that it >> might honor -P or -L. But this is hard to determine, as it depends on the >> specified command. >> >> For now I get the impression, that both, the logical and the physical paths >> are checked. > > When bash is not in Posix mode, it tries, as a last-ditch effort when > using the canonicalized pathname fails, to use what the user typed. This > has been the case since February, 1993, and went in as the result of > user requests. Thx for the clarification. - Reuti -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAljdTiIACgkQo/GbGkBRnRo3FQCgtL4nto3yovW4WMtcZV+CxUWG ddgAoJaGPWT8GLtp1CL6eSbVc6cu7dLS =DHoV -END PGP SIGNATURE-
Re: Symlinks handled inconsistently by cd and wild card expansion
Hi, > Am 30.03.2017 um 09:13 schrieb Topi Mäenpää : > > 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-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 > -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -Wall > uname output: Linux topi 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 > 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > > The cd command remembers where I came from, and "cd .." from a > symlinked directory comes back to the directory of the link. Wild card > expansion works differently and always reads the link target. I > understand the reason in general, but it would make sense that they > behaved the same when used on the command line. > > Repeat-By: > > I have the following directory hierarchy (-> denotes a symlink) > > . > ./a > ./a/1 > ./a/11 > ./a/2 > ./b > ./b/11 -> ../a/11 > ./b/2 -> ../a/2 > ./b/3 > > $ cd b/2 > $ echo ../* # I'd expect to see "../11 ../2 ../3" > ../1 ../11 ../2 > $ cd ../*1* # changes pwd to a/1, expected b/11 > $ cd ../..# back to root > $ cd b/2/../*3* # should go to b/3 > bash: cd: b/2/../*3*: No such file or directory > > Fix: > > When expanding file names on the command line, don't use symlink > targets but the actual paths (pwd or typed). There are the options -P and -L to `pwd` and `cd`, i.e. and `cd -P ..` follows the path up, independent from the symlink, while the default is -L. I don't think that changing it in general would be good, but agree that it might honor -P or -L. But this is hard to determine, as it depends on the specified command. For now I get the impression, that both, the logical and the physical paths are checked. $ tree a b a ├── 1 ├── 11 ├── 2 └── in-A b ├── 2 -> ../a/2 ├── 3 ├── b11 -> ../a/11 └── in-B cd b/2 $ pwd -L /home/reuti/b/2 $ pwd -P /home/reuti/a/2 This is fine. Now a) $ cd $ cd b/2 $ cd ../3 $ pwd -L /home/reuti/b/3 $ pwd -P /home/reuti/b/3 And b) $ cd $ cd b/2 $ cd ../11 $ pwd -L /home/reuti/a/11 $ pwd -P /home/reuti/a/11 Having both `cd` commands working is confusing: Being in b/2 a "cd ../" can target both: the logical and the physical upper directory? I can limit it by -P: $ cd $ cd b/2 $ cd -P ../3 -bash: cd: ../3: No such file or directory This is ok, the 3 is not in a. $ cd $ cd b/2 $ cd -L ../11 $ pwd -L /home/reuti/a/11 $ pwd -P /home/reuti/a/11 This is not ok. -L should limit it to b and throw again an error and not change to a. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: -eq and strings
> Am 06.03.2017 um 15:09 schrieb Rob la Lau :
>
> On 06-03-17 14:18, Greg Wooledge wrote:
>> You're misunderstanding. In a math context, which you are creating here
>> by using -eq, the word 'x' is interpreted as a variable name, which may
>> contain another variable name, and so on, until finally an integer is
>> discovered.
>
> Thanks. Now that I know it, I can indeed find it in the docs.
>
> I guess this means that actually test and [ are 'broken':
>
> $ test "x" -eq "x" && echo "yes" || echo "no"
> test: invalid integer 'x'
> no
>
> $ [ "x" -eq "x" ] && echo "yes" || echo "no"
> [: invalid integer 'x'
> no
>
> I hope this won't be fixed, as I rely quite heavily on this behaviour,
> lacking some other short 'is integer' test.
What about these:
if ! expr "$x" : '[[:digit:]]*$' >/dev/null; then echo no; fi
if [ -n "${x//[0-9]/}" ]; then echo no; fi
-- Reuti
>
> Cheers,
> Rob
>
> --
> -- Rob la Lau
> --
> -- Sysadmin en webdeveloper in ruste
> --
> -- web : https://ohreally.nl/
> -- eml : r...@ohreally.nl
> --
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
Am 01.03.2017 um 22:14 schrieb Chet Ramey: >> […] >> >> is still there. > > This was fixed back in November as part of the work prompted by this > report: > > http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00101.html > > I've attached a patch people can play around with. Indeed, then it's working too. Thx -- Reuti
Re: "Variation" in Command Substitution Behaviour
Am 01.03.2017 um 21:24 schrieb Grisha Levit: > On Wed, Mar 1, 2017 at 3:08 PM, Reuti wrote: >> I would say not closed, as it's still happening in 4.4.12. And if it's >> closed, it should be reopened. > > Are you using the same example? I can reproduce Geoff's original test > case with 4.3 but not with 4.4.. Ok, I can't reproduce the issue he found - correct this is gone. But the behavior I found: bash-4.4$ reset_vars bash-4.4$ assemble_fam2 bash-4.4$ assemble_fam1 bash-4.4$ say_families Flintstones=wilma:bam-bam:fred Rubbles=barney is still there. -- Reuti
Re: "Variation" in Command Substitution Behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.03.2017 um 20:27 schrieb Geoff Hull: > Aha! That's it. Case closed, I think. I would say not closed, as it's still happening in 4.4.12. And if it's closed, it should be reopened. - -- Reuti -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAli3KlgACgkQo/GbGkBRnRr7hwCfUS0Oz/24PDVd1NXWYoPhSpW+ xNwAn0E48nzFkt1HTQWuzXkaY0sOP6Vw =n5oM -END PGP SIGNATURE-
Re: "Variation" in Command Substitution Behaviour
> Am 01.03.2017 um 16:53 schrieb Grisha Levit : > > On Mar 1, 2017 1:04 AM, "Geoff Hull" wrote: > If I want to go back to the behaviour I first experienced then I put the > default COMMAND_PROMPT back > > I reported the multi-line alias and PROMPT_COMMAND interaction last June. The > behavior you note should be fixed in 4.4. > > https://lists.gnu.org/archive/html/bug-bash/2016-06/msg00020.html Aha, typo - yes: setting PROMPT_COMMAND gives your reported behavior Grisha. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
Hi,
> Am 01.03.2017 um 07:04 schrieb Geoff Hull :
>
> Hi Reuti, Andreas,
>
> Yes, forgot to mention the bash versions I have tried: 4.3.46 on Arch Linux
> and 4.1.2 on CentOS 6.8.
>
> This is getting weirder: I've found I can replicate the behaviour you are
> getting Reuti, if I first do this command:
>
> unset COMMAND_PROMPT
>
> If I want to go back to the behaviour I first experienced (i.e.
> Rubbles=barney after running assemble_fam1 then assemble_fam2), then I put
> the default COMMAND_PROMPT back:
>
> PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}"
> "${PWD/#$HOME/~}"'
>
> Does this work the same for you?
No, it doesn't change anything setting, unsetting and/or exporting it. Is it a
Bash environment variable? I set PS1 on openSUSE for the prompt.
BTW: On a Mac with Bash 4.3.30(1) it works fine all the time, whatever order of
executed aliases I use.
-- Reuti
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
> Am 28.02.2017 um 14:21 schrieb Reuti : > > Hi, > >> Am 28.02.2017 um 11:00 schrieb Andreas Schwab : >> >> On Feb 28 2017, Geoff Hull wrote: >> >>> If I "source" the attached file (i.e. ". test_aliases") in a bash session, >>> then run the following: >>> >>> assemble_fam1 >>> assemble_fam2 >>> say_families >>> >>> I see the following output: >>> >>> Flintstones=wilma:bam-bam:fred >>> Rubbles=barney Using the syntax $() for both functions renders also the order above unusable (here FSTONES will get reset by assemble_fam2 then). Like $() will revert an unrelated variable to a former state. There also seems to be difference between using run_aliases or issuing both commands by hand. Using `` for both functions looks like being safe though and covers all cases. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
Hi, > Am 28.02.2017 um 11:00 schrieb Andreas Schwab : > > On Feb 28 2017, Geoff Hull wrote: > >> If I "source" the attached file (i.e. ". test_aliases") in a bash session, >> then run the following: >> >> assemble_fam1 >> assemble_fam2 >> say_families >> >> I see the following output: >> >> Flintstones=wilma:bam-bam:fred >> Rubbles=barney In which version of Bash are you observing this? For me it's working using this order, but when I swap assemble_fam1 and assemble_fam2 I observe a strange behavior, that RUBBLES gets reset and I get your output: $ assemble_fam1 $ assemble_fam2 $ say_families Flintstones=wilma:bam-bam:fred Rubbles=betty:pebbles:barney $ reset_vars $ assemble_fam2 $ say_families Flintstones= Rubbles=betty:pebbles:barney $ assemble_fam1 $ say_families Flintstones=wilma:bam-bam:fred Rubbles=barney This I have in 4.2 and 4.4. $ reset_vars + reset_vars + unset FSTONES RUBBLES $ assemble_fam2 + barney ++ echo barney + RUBBLES=barney $ say_families + RUBBLES=betty:pebbles:barney + say_families + echo Flintstones= Flintstones= + echo Rubbles=betty:pebbles:barney Rubbles=betty:pebbles:barney $ assemble_fam1 + fred ++ echo fred + FSTONES=fred + FSTONES=wilma:bam-bam:fred $ say_families + say_families + echo Flintstones=wilma:bam-bam:fred Flintstones=wilma:bam-bam:fred + echo Rubbles=barney Rubbles=barney > It seems like the shell is eating an extra newline. Try typing an empty > line after assemble_fam2: The extra newline doesn't help for the observation above. While defining assemble_famX in one line for both does as mentioned by Geoff. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: here-documents in $(command) substitution
Am 27.11.2016 um 18:51 schrieb Eduardo Bustamante: > Hi Alexey, > > Please read the specification of here-documents in the standard: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04 > > Quoting the relevant parts: > >The here-document shall be treated as a single word that begins > after the next and continues until there is a line > containing only the delimiter and a , with no > characters in between. Then the next here-document starts, if there is > one. [...] > >[n]<here-document >delimiter > > Delimiter (in your case the three character string "EOF"), has to be > on its own line, with no leading or trailing blanks (or any other > characters). If bash 3.x used to behave different, it's because it was > buggy. > > Hence, the proper way to do a here-document inside command substitution: My understanding was that he is referring to the strange behavior in case of a malformed syntax. Why is "baz" output at all then? -- Reuti > >hp% cat hd >export foo=$(cat <echo bar >EOF >) >echo baz >hp% bash hd >baz >
Re: Racing condition leads to unstable exit code
Hi,
> Am 30.09.2016 um 16:11 schrieb Luiz Angelo Daros de Luca :
>
> Yes, this is the part that I agree. However, this is the other behavior of
> bash wait (from bash manual)
>
> "When Bash is waiting for an asynchronous command via the wait builtin, the
> reception of a signal for which a trap has been set will cause the wait
> builtin to return immediately with an exit status greater than 128,
> immediately after which the trap is executed."
>
> The behavior is the same for when parent or child receives the signal. When
> it's the parent process that received it, child might still be running. It
> simply breaks the logic of wait. In order to wait until the child exits even
> when signal was received, I need to implement a new wait command (with some
> hacks) like this (untested):
I don't know the process set up you want to achieve, but maybe it helps when
you send the signal to the complete process group, and not only the parent
process. Specifying a negative PID to `kill` will initiate this.
-- Reuti
>
> usr1(){
> got_signal=true
> Do something...
> }
>
> wait2() {
> while true; do
> got_signal=false
> wait $*
> exitcode=$?
> $got_signal || return $exitcode
> }
>
> trap usr1 USR1
>
> ( Child stuff... Send USR1 to parent ) &
> wait2 $!
>
>
>
> Em sex, 30 de set de 2016 09:45, Chet Ramey escreveu:
> On 9/29/16 10:58 PM, Luiz Angelo Daros de Luca wrote:
> > No problem! I already workarounded it using pipe as a semaphore. Thanks!
> >
> > It's there any chance of changing the 128+signal exit code for wait when
> > trap is received?
> > It might solve some special usecase which I'm not aware. Wait should always
> > returns exit code related to the child process, except for 127.
>
> The shell is required to do this, and it's historical shell behavior. If
> a process is killed by signal N, its exit status is 128+N. That's how
> scripts know their children were killed due to a signal.
>
>
> > The 128+signal behavior is not even mentioned on wait documentation but on
> > signal section! If wait returns 129, I don't know wether child died because
> > of signal 1 (128+1) or if it is the current instance that received the
> > signal instead.
>
> Posix says:
>
> "When the shell is waiting, by means of the wait utility, for asynchronous
> commands to complete, the reception of a signal for which a trap has been
> set shall cause the wait utility to return immediately with an exit status
> >128, immediately after which the trap associated with that signal shall be
> taken."
>
> If you want the shell to be insulated from signals that might be sent to
> its children, you either have to use job control, which works for the
> keyboard-generated signals that go to process groups, or ignore the signal
> using trap to be sure you don't receive it.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
> --
> Luiz Angelo Daros de Luca
> luizl...@gmail.com
>
Re: Execution of a data string
> Am 22.09.2016 um 15:23 schrieb Greg Wooledge : > > On Wed, Sep 21, 2016 at 11:15:45PM -0400, mobatu...@yahoo.ca wrote: >> In Summary: >> >> declare -a "$string" # results in execution of $string >> declare -a a=($string)# does not result in execution of $string > > This is why you don't use the first form. It's the same with eval -- > if you don't have full control over the statement being eval'ed, then > you risk undesired code execution. Even without `eval` it's dangerous, i.e. specifying solely $ExecuteThisData on the command line. -- Reuti > Your second form also has some issues. The contents of $string will > undergo word splitting and then pathname expansion (globbing). This could > cause unexpected results if any of the words expands to a glob pattern > which matches actual files. If you want to split a string into an array, > this is safer as long as the string does not contain any newlines: > > read -ra a <<< "$string" > > If the string contains newlines, then: > > read -rd '' -a a <<< "$string" > > Of course, this read command will always exit with status "1" because > it never finds a NUL byte. That's only a problem if you use set -e, > which of course no sane person should be doing >
Re: bug in [ -f file ] test
> Am 27.07.2016 um 18:55 schrieb László Házy : > > Here it goes. Note that the second command you asked for returns the same as > the "file" entry in the first command. Thanks. Yeah, I meant: $ ls -Zd /home/user1 to show the entry of the directory itself, not its content. - Reuti > [user1]$ ls -Z /home/user1 > unconfined_u:object_r:user_home_t:s0 Desktop > unconfined_u:object_r:user_home_t:s0 Documents > unconfined_u:object_r:user_home_t:s0 Downloads > unconfined_u:object_r:user_home_t:s0 file > unconfined_u:object_r:audio_home_t:s0 Music > unconfined_u:object_r:user_home_t:s0 Pictures > unconfined_u:object_r:user_home_t:s0 Public > unconfined_u:object_r:user_home_t:s0 Templates > unconfined_u:object_r:user_home_t:s0 Videos > > > > > On Wed, 2016-07-27 at 18:28 +0200, Reuti wrote: >>> >>> Am 27.07.2016 um 18:13 schrieb László Házy < >>> haz...@yahoo.com >>> >: >>> >>> Yes, SELinux is active. >>> >> >> >> Fine. >> >> Can you please provide: >> >> $ ls -Z /home/user1 >> $ ls -Z /home/user1/file >> >> -- Reuti >> >> >> >>> >>> On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: >>> >>>> >>>>> >>>>> >>>>> Am 27.07.2016 um 17:36 schrieb László Házy < >>>>> >>>>> haz...@yahoo.com >>>>>> >>>>>> : >>>>>> >>>>> >>>>> >>>>> Yes, user2 has rx access to /home/user1. This is done by the first >>>>> command in the list of commands, namely: "[user1]$ chmod g+rx >>>>> /home/user1". The two users are part of the same group. >>>>> >>>>> An even more troublesome variation, involving root, is the following: >>>>> >>>>> [user1]$ touch file; ls -l file >>>>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>>>> >>>>> >>>> >>>> >>>> >>>> The dot at the end means SELinux ACL IIRC - are you running SELinux? >>>> >>>> -- Reuti >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> [user1]$ ln -s /home/user1/file /var/tmp/link >>>>> [user1]$ ls -l /var/tmp/link >>>>> lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> >>>>> /home/user1/file >>>>> >>>>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>>>> 0 >>>>> >>>>> [user1]$ su >>>>> [root]$ [[ -f /var/tmp/link ]]; echo $? >>>>> 1 >>>>> >>>>> >>>>> On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> Am 26.07.2016 um 23:07 schrieb László Házy: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hmm, interesting. I can reproduce your results. Thanks. >>>>>>> However, note the following: >>>>>>> >>>>>>> [user1]$ chmod g+rx /home/user1 >>>>>>> [user1]$ touch file; ls -l file >>>>>>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>>>>>> >>>>>>> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" >>>>>>> [user1]$ ls -l /var/tmp/link >>>>>>> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> >>>>>>> /home/user1/file >>>>>>> >>>>>>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>>>>>> 1 >>>>>>> >>>>>>> [user1]$ su user2 >>>>>>> [user2]$ [[ -f /var/tmp/link ]]; echo $? >>>>>>> 0 >>>>>>> >>>>>>> Something does not add up. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Does user2 have rx access to /home/user1? >>>>>> >>>>>> -- Reuti >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From experimenting, it appears that only the user who created the >>>>>>> symlink will get true for the file test. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Are you sure "file" is a link to an actual file, not, say, a directory? >>>>>>>> >>>>>>>> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >>>>>>>> bash-4.3.42-3.fc23.x86_64 >>>>>>>> 4.3.42(1)-release >>>>>>>> Fedora release 23 (Twenty Three) >>>>>>>> >>>>>>>> $ touch file; ln -s file link; [[ -f link ]]; echo $? >>>>>>>> 0 >>>>>>>> >>>>>>>> On Tue, Jul 26, 2016 at 12:58 PM, László Házy < >>>>>>>> >>>>>>>> >>>>>>>> haz...@yahoo.com >>>>>>>>> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am running bash 4.3.42-3 on Fedore Core 23. >>>>>>>>> >>>>>>>>> I noticed that the [ -f file ] test returns false if "file" is a >>>>>>>>> symlink. Given the intended behavior (from a long time ago), this is >>>>>>>>> wrong as the symlinks are supposed to be followed. It certainly >>>>>>>>> brakes functionality in certain existing software. >>>>>>>>> >>>>>>>>> Has the default behavior been changed somewhere along the time line >>>>>>>>> and I am not aware of it? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >>
Re: bug in [ -f file ] test
> Am 27.07.2016 um 18:13 schrieb László Házy : > > Yes, SELinux is active. Fine. Can you please provide: $ ls -Z /home/user1 $ ls -Z /home/user1/file -- Reuti > On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: >>> >>> Am 27.07.2016 um 17:36 schrieb László Házy < >>> haz...@yahoo.com >>> >: >>> >>> Yes, user2 has rx access to /home/user1. This is done by the first command >>> in the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two >>> users are part of the same group. >>> >>> An even more troublesome variation, involving root, is the following: >>> >>> [user1]$ touch file; ls -l file >>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>> >> >> >> The dot at the end means SELinux ACL IIRC - are you running SELinux? >> >> -- Reuti >> >> >> >>> >>> [user1]$ ln -s /home/user1/file /var/tmp/link >>> [user1]$ ls -l /var/tmp/link >>> lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file >>> >>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>> 0 >>> >>> [user1]$ su >>> [root]$ [[ -f /var/tmp/link ]]; echo $? >>> 1 >>> >>> >>> On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: >>> >>>> >>>> Am 26.07.2016 um 23:07 schrieb László Házy: >>>> >>>> >>>> >>>>> >>>>> >>>>> Hmm, interesting. I can reproduce your results. Thanks. >>>>> However, note the following: >>>>> >>>>> [user1]$ chmod g+rx /home/user1 >>>>> [user1]$ touch file; ls -l file >>>>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>>>> >>>>> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" >>>>> [user1]$ ls -l /var/tmp/link >>>>> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> >>>>> /home/user1/file >>>>> >>>>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>>>> 1 >>>>> >>>>> [user1]$ su user2 >>>>> [user2]$ [[ -f /var/tmp/link ]]; echo $? >>>>> 0 >>>>> >>>>> Something does not add up. >>>>> >>>>> >>>> >>>> >>>> >>>> Does user2 have rx access to /home/user1? >>>> >>>> -- Reuti >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> From experimenting, it appears that only the user who created the symlink >>>>> will get true for the file test. >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> Are you sure "file" is a link to an actual file, not, say, a directory? >>>>>> >>>>>> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >>>>>> bash-4.3.42-3.fc23.x86_64 >>>>>> 4.3.42(1)-release >>>>>> Fedora release 23 (Twenty Three) >>>>>> >>>>>> $ touch file; ln -s file link; [[ -f link ]]; echo $? >>>>>> 0 >>>>>> >>>>>> On Tue, Jul 26, 2016 at 12:58 PM, László Házy < >>>>>> >>>>>> haz...@yahoo.com >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> I am running bash 4.3.42-3 on Fedore Core 23. >>>>>>> >>>>>>> I noticed that the [ -f file ] test returns false if "file" is a >>>>>>> symlink. Given the intended behavior (from a long time ago), this is >>>>>>> wrong as the symlinks are supposed to be followed. It certainly brakes >>>>>>> functionality in certain existing software. >>>>>>> >>>>>>> Has the default behavior been changed somewhere along the time line and >>>>>>> I am not aware of it? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >>
Re: bug in [ -f file ] test
> Am 27.07.2016 um 17:36 schrieb László Házy : > > Yes, user2 has rx access to /home/user1. This is done by the first command in > the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two > users are part of the same group. > > An even more troublesome variation, involving root, is the following: > > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file The dot at the end means SELinux ACL IIRC - are you running SELinux? -- Reuti > [user1]$ ln -s /home/user1/file /var/tmp/link > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user1 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > [user1]$ su > [root]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > > On Tue, 2016-07-26 at 23:26 +0200, Reuti wrote: >> Am 26.07.2016 um 23:07 schrieb László Házy: >> >> >>> >>> Hmm, interesting. I can reproduce your results. Thanks. >>> However, note the following: >>> >>> [user1]$ chmod g+rx /home/user1 >>> [user1]$ touch file; ls -l file >>> -rw-r--r--. 1 user1 users0 Jul 26 15:24 file >>> >>> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" >>> [user1]$ ls -l /var/tmp/link >>> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file >>> >>> [user1]$ [[ -f /var/tmp/link ]]; echo $? >>> 1 >>> >>> [user1]$ su user2 >>> [user2]$ [[ -f /var/tmp/link ]]; echo $? >>> 0 >>> >>> Something does not add up. >>> >> >> >> Does user2 have rx access to /home/user1? >> >> -- Reuti >> >> >> >>> >>> From experimenting, it appears that only the user who created the symlink >>> will get true for the file test. >>> >>> Thank you. >>> >>> >>> >>> >>> On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >>> >>>> >>>> Are you sure "file" is a link to an actual file, not, say, a directory? >>>> >>>> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >>>> bash-4.3.42-3.fc23.x86_64 >>>> 4.3.42(1)-release >>>> Fedora release 23 (Twenty Three) >>>> >>>> $ touch file; ln -s file link; [[ -f link ]]; echo $? >>>> 0 >>>> >>>> On Tue, Jul 26, 2016 at 12:58 PM, László Házy < >>>> haz...@yahoo.com >>>> > wrote: >>>> >>>>> >>>>> I am running bash 4.3.42-3 on Fedore Core 23. >>>>> >>>>> I noticed that the [ -f file ] test returns false if "file" is a symlink. >>>>> Given the intended behavior (from a long time ago), this is wrong as the >>>>> symlinks are supposed to be followed. It certainly brakes functionality >>>>> in certain existing software. >>>>> >>>>> Has the default behavior been changed somewhere along the time line and I >>>>> am not aware of it? >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >>
Re: bug in [ -f file ] test
Am 26.07.2016 um 23:07 schrieb László Házy: > Hmm, interesting. I can reproduce your results. Thanks. > However, note the following: > > [user1]$ chmod g+rx /home/user1 > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" > [user1]$ ls -l /var/tmp/link > lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file > > [user1]$ [[ -f /var/tmp/link ]]; echo $? > 1 > > [user1]$ su user2 > [user2]$ [[ -f /var/tmp/link ]]; echo $? > 0 > > Something does not add up. Does user2 have rx access to /home/user1? -- Reuti > From experimenting, it appears that only the user who created the symlink > will get true for the file test. > > Thank you. > > > > > On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >> Are you sure "file" is a link to an actual file, not, say, a directory? >> >> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >> bash-4.3.42-3.fc23.x86_64 >> 4.3.42(1)-release >> Fedora release 23 (Twenty Three) >> >> $ touch file; ln -s file link; [[ -f link ]]; echo $? >> 0 >> >> On Tue, Jul 26, 2016 at 12:58 PM, László Házy wrote: >>> I am running bash 4.3.42-3 on Fedore Core 23. >>> >>> I noticed that the [ -f file ] test returns false if "file" is a symlink. >>> Given the intended behavior (from a long time ago), this is wrong as the >>> symlinks are supposed to be followed. It certainly brakes functionality in >>> certain existing software. >>> >>> Has the default behavior been changed somewhere along the time line and I >>> am not aware of it? >>> >>> >>
Re: [Documentation] -d returns true for symlink to directory
> Am 21.07.2016 um 23:38 schrieb Bob Proulx : > > Reuti wrote: >> While we are on this: wondering about the difference about -h and -L I found >> that `man test` outputs on OS X: >> >> " -h file True if file exists and is a symbolic link. This >> operator is retained for compatibility with pre- >> vious versions of this program. Do not rely on its >> existence; use -L instead." >> >> while on Linux `man test` just states that it's the same. Is there any >> preference which one should be used for the bash builtin? > > Originally Unix did not provide symlinks. Then when symlinks were > added they were not completely added in a uniform regular way through > every command. Bummer! > > The original option letter used by test to check for the presence of a > symlink was -h. I don't know why. But in those days the only test > option to test for a symlink was -h. The -L came later. This legacy > is still visible in the HP-UX test man page for example. No -L > documented there. > > http://nixdoc.net/man-pages/HP-UX/man1/test.1.html > > However note that because POSIX requires it the /bin/sh posix shell > must implement -L as identical to -h. And the reverse. Therefore you > are safe to use either on any POSIX system. Remember too that POSIX > wasn't originally meant as a design document but as an OS feature > non-proliferation treaty to make it possible to write portable > programs. POSIX features must be present on any POSIX system and > therefore you can use the feature and expect it to work. Thx for this historical digest. -- Reuti > If you need to interact with legacy systems which predate POSIX and > have never been updated to comply then you must use -h because that is > all there is there. But if you never interact with anything non-POSIX > then using -L is okay too. Either is the same as the other now. > > I think the statement in the Apple man page is there because someone > liked -L over -h and wanted to scare everyone into using one over the > other. But there isn't any reason to do so. > > Bob >
Re: [Documentation] -d returns true for symlink to directory
Hi, > Am 21.07.2016 um 15:39 schrieb Greg Wooledge : > > On Wed, Jul 20, 2016 at 04:43:13PM -0700, Adam McKenna wrote: >> -d file >> True if file exists and is a directory. >> >> The operator also returns True if the file exists and is a symlink to a >> directory > > Yes. All of the file-testing operators follow a symlink, EXCEPT for the > ones that specifically test whether the operand is a symlink (-h and -L). While we are on this: wondering about the difference about -h and -L I found that `man test` outputs on OS X: " -h file True if file exists and is a symbolic link. This operator is retained for compatibility with pre- vious versions of this program. Do not rely on its existence; use -L instead." while on Linux `man test` just states that it's the same. Is there any preference which one should be used for the bash builtin? -- Reuti
Re: [Documentation] -d returns true for symlink to directory
Hi, > Am 21.07.2016 um 01:43 schrieb Adam McKenna : > > BASH Man page conditional expressions: > >-d file > True if file exists and is a directory. > > This is also stated at https://www.gnu.org/software/bash/manual/bashref.html > > The operator also returns True if the file exists and is a symlink to a > directory > > -bash-4.1$ file foo > foo: directory > -bash-4.1$ file bar > bar: symbolic link to `foo' > -bash-4.1$ if [ -d bar ]; then echo "bar is a directory"; fi > bar is a directory > -bash-4.1$ if [ -h bar ]; then echo "bar is a symlink"; fi > bar is a symlink > -bash-4.1$ bash -version > GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > > This is free software; you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > If this is intended behavior, the manual page and other documentation should > be updated to reflect it. There is a line above the list in the man page: "Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself." -- Reuti
Re: Possible bash bug?
> Am 22.06.2016 um 11:34 schrieb John Lawlor : > > Hi, > > I came across some unusual behaviour in bash using the ‘-c’ parameter. > > If I do the following: > > bash -c "ping 127.0.0.1 > $HOME/console.log" & > > This starts two processes bash and ping: > > john 18038 17951 0 09:26 pts/14 00:00:00 bash -c ping 127.0.0.1 > > /home/john/console.log > john 18039 18038 0 09:26 pts/14 00:00:00 ping 127.0.0.1 > > From the process hierarchy bash is the parent process of ping. > > Now if I kill bash: > > kill -15 18038 This kills just the specified process. What does happen when you issue: $ kill %1 (resp. the the number output when issuing the above command) instead? -- Reuti > And check the process tree again: > > UIDPID PPID C STIME TTY TIME CMD > john 17951 30467 0 09:25 pts/14 00:00:00 /bin/bash > john 18039 1 0 09:26 pts/14 00:00:00 ping 127.0.0.1 > john 18064 17951 0 09:30 pts/14 00:00:00 ps -f > [1]+ Terminated bash -c "ping 127.0.0.1 > $HOME/console.log" > > Bash is killed but not the child ping process. I was expecting that to be > killed also. > > If I repeat the exact same steps with ksh –c, it does kill the ping process. > > It looks like bash does a double fork or something whereas ksh does only an > execute without fork. > > Regards, > John > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you are not the intended recipient, please note that any review, > dissemination, disclosure, alteration, printing, circulation, retention or > transmission of this e-mail and/or any file or attachment transmitted with > it, is prohibited and may be unlawful. If you have received this e-mail or > any file or attachment transmitted with it in error please notify > postmas...@openet.com. Although Openet has taken reasonable precautions to > ensure no viruses are present in this email, we cannot accept responsibility > for any loss or damage arising from the use of this email or attachments.
Re: Cannot grep jobs list when jobs called in a function
> Am 29.04.2016 um 15:44 schrieb Greg Wooledge :
>
> On Fri, Apr 29, 2016 at 03:32:22PM +0200, Reuti wrote:
>> I understand that the behavior of the builtin `jobs` changes, in case it
>> discovers that it's run a subshell. But what is happening here:
>>
>> $ sleep 300 &
>> [1] 31766
>> $ function lister() { date; jobs; }
>> $ lister
>> Fri Apr 29 15:29:46 CEST 2016
>> [1]+ Running sleep 300 &
>> $ lister | cat
>> Fri Apr 29 15:30:00 CEST 2016
>> [1] Donedate
>>
>> My question is: why does the `date` command show up as "done" at all? I
>> would expect the output to be just empty.
>
> I don't fully understand either. Note that the "Done" job is reported
> as "date" instead of "sleep". It would seem the subshell is trying to
> keep track of processes but has become confused.
>
>> Depending on the overall program, this might work to avoid a subshell:
>>
>> if grep -q vim < <(realjobs); then ...
>
> No, that runs "realjobs" in a background subshell. You're thinking of
> the use of a process substitution to keep the grep in the foreground,
> but here it's the "realjobs" part that has to be kept in the foreground.
I tested with this:
$ function lister() { date; jobs; }
$ sleep 300 &
[1] 1931
$ if grep sleep < <(lister); then echo Yes; fi
[1]+ Running sleep 300 &
Yes
-- Reuti
Re: Cannot grep jobs list when jobs called in a function
> Am 29.04.2016 um 14:15 schrieb Greg Wooledge :
>
> On Thu, Apr 28, 2016 at 10:38:53AM -0600, Eric Blake wrote:
>> Bash has code to special-case 'jobs |' when it can obviously tell that
>> you are running the jobs builtin as the sole command of the left side of
>> a pipe, to instead report about the jobs of the parent shell,
>
> Oh, that's interesting. I didn't know that.
Me too.
I understand that the behavior of the builtin `jobs` changes, in case it
discovers that it's run a subshell. But what is happening here:
$ sleep 300 &
[1] 31766
$ function lister() { date; jobs; }
$ lister
Fri Apr 29 15:29:46 CEST 2016
[1]+ Running sleep 300 &
$ lister | cat
Fri Apr 29 15:30:00 CEST 2016
[1] Donedate
My question is: why does the `date` command show up as "done" at all? I would
expect the output to be just empty.
> but that
>> special-case code cannot kick in if you hide the execution of jobs,
>> whether by hiding it inside a function as you did, or by other means
>> such as:
>> $ eval jobs | grep vim
>
> In general, if you want to filter the output of "jobs" or some other
> builtin that changes its behavior when invoked in a subshell, then
> you need to avoid the subshell. That means no pipeline, no command
> substitution, etc. Basically that leaves you with a temporary file.
>
> tmpfile=... # boilerplate code to create a temp file on whatever OS
> trap 'rm -f "$tmpfile"' EXIT
> jobs > "$tmpfile"
> if grep -q vim "$tmpfile"; then ...
Depending on the overall program, this might work to avoid a subshell:
if grep -q vim < <(realjobs); then ...
-- Reuti
Re: Cannot grep jobs list when jobs called in a function
> Am 29.04.2016 um 15:32 schrieb Reuti :
>
>
>> Am 29.04.2016 um 14:15 schrieb Greg Wooledge :
>>
>> On Thu, Apr 28, 2016 at 10:38:53AM -0600, Eric Blake wrote:
>>> Bash has code to special-case 'jobs |' when it can obviously tell that
>>> you are running the jobs builtin as the sole command of the left side of
>>> a pipe, to instead report about the jobs of the parent shell,
>>
>> Oh, that's interesting. I didn't know that.
>
> Me too.
>
> I understand that the behavior of the builtin `jobs` changes, in case it
> discovers that it's run a subshell. But what is happening here:
>
> $ sleep 300 &
> [1] 31766
> $ function lister() { date; jobs; }
> $ lister
> Fri Apr 29 15:29:46 CEST 2016
> [1]+ Running sleep 300 &
> $ lister | cat
> Fri Apr 29 15:30:00 CEST 2016
> [1] Donedate
>
> My question is: why does the `date` command show up as "done" at all? I would
> expect the output to be just empty.
In detail: the output of the `jobs` command. - Reuti
> but that
>>> special-case code cannot kick in if you hide the execution of jobs,
>>> whether by hiding it inside a function as you did, or by other means
>>> such as:
>>> $ eval jobs | grep vim
>>
>> In general, if you want to filter the output of "jobs" or some other
>> builtin that changes its behavior when invoked in a subshell, then
>> you need to avoid the subshell. That means no pipeline, no command
>> substitution, etc. Basically that leaves you with a temporary file.
>>
>> tmpfile=... # boilerplate code to create a temp file on whatever OS
>> trap 'rm -f "$tmpfile"' EXIT
>> jobs > "$tmpfile"
>> if grep -q vim "$tmpfile"; then ...
>
> Depending on the overall program, this might work to avoid a subshell:
>
> if grep -q vim < <(realjobs); then ...
>
> -- Reuti
>
>
>
>
Re: Bash $@ Parameter Variable Breaking Out of Strings
> Am 22.03.2016 um 15:47 schrieb Adam Danischewski
> :
>
> I noticed an issue using the parameter built-in variable $@ breaking
> out of contained strings when utilized in functions.
>
> For example, consider the following bash script: m.bsh
> #!/bin/bash
> echo "$#"
> while getopts d: OPTION "$@"; do
> case "$OPTION" in
>d)
> echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
> [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
> ;;
> esac
> done
> exit 0
>
> $ alias t1='_() { var=$@; /tmp/m.bsh -d "clarify ${var}"; }; _'
> $ t1 hi there
> 2
> the optarg is clarify hi there, optind is 3
> ### Correctly considers the text as a single string argument
> containing a space.
>
> $ alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
alias t2='_() { $HOME/m.bsh -d "clarify $*"; }; _'
might help.
For "$@" the man page says: If the double-quoted expansion occurs within a
word, the expansion of the first parameter is joined with the beginning part
of the original word [...]
-- Reuti
> $ t2 hi there
> 3
> the optarg is clarify hi, optind is 3
> ### Incorrectly breaks the argument array variable out as separate
> single string arguments.
>
> I noticed another interesting occurrence as well, I'm not sure if they are
> related, to variable names:
>
> function update() {
> local -i VAR=45
> VAR+=-1
> VAR+=$1
> echo $VAR
> }
>
> $ VAR2=2
> $ update VAR2
> 47
>
> $ VAR=3
> $ update VAR
> 88 ### !?
>
>
Re: bash can't distinguish between empty and unset arrays
Hi,
Am 04.02.2016 um 00:43 schrieb Martijn Dekker:
> bash treats an empty array as if it were an unset variable, which seems
> very illogical as empty is quite distinct from unset:
>
> $ myarray=()
> $ [[ -v myarray ]] && echo set || echo unset
> unset
Which version of bash are you using?
> $ set | grep ^myarray=# yet, it's set:
> myarray=()
> $ set -u
Doesn't -u force just the behavior you observe, what if using +u?
-- Reuti
> $ for i in "${x[@]}"; do :; done
> bash: x[@]: unbound variable
>
> Note also that the "unbound variable" error is inconsistent with the
> behaviour of "$@"; I would have thought that, logically, "$@" and
> "${x[@]}" should behave the same way, since arrays are implemented as a
> logical extension of the positional parameters concept.
>
> zsh and ksh93 can distinguish between empty and unset arrays.
>
> Thanks,
>
> - Martijn
>
Re: read Built-in Parameter Behavior -- Null Byte Delimiter
Greg, Am 25.01.2016 um 19:52 schrieb Greg Wooledge: > On Mon, Jan 25, 2016 at 07:09:27PM +0100, Reuti wrote: >> Sometimes I miss a feature in Bash to get access to the plain command line >> the user typed, including all quotes and other redirections > > There is a way to do this, but it is not a path for the sane. > > http://www.chiark.greenend.org.uk/~sgtatham/aliases.html Thanks a bunch. This hack was exactly what I was looking for - looks like I'm not the first one having a need for it. Inside the function I had to use () to get a subshell to avoid that "str" is known after the issued command, but I get the exact command line in the job's comment this way now. -- Reuti
Re: Leak in BASH "named" file descriptors?
Hi, Am 28.01.2016 um 23:25 schrieb Andreas Schwab: > Mathieu Patenaude writes: > >> The issue I see with relying on the bash EXIT to actually have the system >> do the cleanup is when you have a script that does things in a forever >> loop, you end up with FD exhaustion when using "named" FD and here strings. > > Of course, if you don't close (or reuse) your descriptors you will run > out of them eventually. The man page of bash 4.2 says about REDIRECTION: In this case [...] the shell will allocate a file descriptor greater than 10 and assign it to varname. While looking into this discussion, I get 10 as first varname assigned in this way. Either a bug in bash or the man page? -- Reuti > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." >
Re: read Built-in Parameter Behavior -- Null Byte Delimiter
Hi, > Am 19.01.2016 um 17:49 schrieb Greg Wooledge : > > On Tue, Jan 19, 2016 at 11:39:07AM -0500, Adam Danischewski wrote: >> Bash also removes the single quotes before it hits read when the single >> quotes are attached to the delimiter option (-d''). > > And in EVERY OTHER COMMAND. This is how quotes work. This is utterly > fundamental to bash and the entire Bourne shell syntax. > > echo ""'a'''$''""'' > > Is *exactly* the same as > > echo a > > Echo has no way to know that you typed a and not "a" or a"" or 'a' or Sometimes I miss a feature in Bash to get access to the plain command line the user typed, including all quotes and other redirections - just as someone would press the cursor up key on the command line to get the last line. E.g. like an environment variable INVOCATION_LINE which I can check in a started script. The reason for this is to remember the exact command the user typed to submit a job to our queuingsystems in our clusters (there is a field for comments in the queuingsystem, and the users requested a feature to look up what they typed initially at a later point in time, i.e. when the job has finished, for exactly this particular job - so the bash history is no option here). Sure, I can take the command line and enclose all options in quotes and put this in the comment field. But this won't work in case some path expansion took place, process substitutions, input/output redirections, using quotes in arguments. -- Reuti
Re: aliases v. functions; command extension? (-f & -F)?
> Am 11.01.2016 um 15:52 schrieb Chet Ramey : > > On 1/9/16 2:12 PM, Reuti wrote: >> >> Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski: >> >>> hello Linda, >>> >>> On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote: >>>> >>>> For what it's worth, It might be useful to have something like >>>> 'command' [..] >>> >>> that would be useful, a keyword like: >>> >>> function p params; >> >> AFAICS putting the name in quotes (single or double) will prefer the >> function over the alias, but it will fall back to a command if there is no >> function. >> >> 'P' params > > Yes, quoting any part of a command name inhibits alias expansion, since the > quotes remain as part of the word when alias expansion is performed. > > >> Does: >> >> type - a P >> >> list them in order? It seems always to be in the order alias - function - >> command. > > Yes. The output is intended to show how a name would be resolved if used > as a command. The order is > > alias > reserved word > function > builtin > command hash table > PATH search Great. May I suggest to add this table to the man page? In section "COMMAND EXECUTION" it's already explained in the text, but such a table would be handy. -- Reuti > Posix mode changes this slightly. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: aliases v. functions; command extension? (-f & -F)?
Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski:
> hello Linda,
>
> On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote:
>>
>> For what it's worth, It might be useful to have something like
>> 'command' [..]
>
> that would be useful, a keyword like:
>
> function p params;
AFAICS putting the name in quotes (single or double) will prefer the function
over the alias, but it will fall back to a command if there is no function.
'P' params
> that always calls function no matter what. maybe best would be to have
> something like:
>
> run -f fname params # if (f=find_function("fname"))!=null executes f else
> error
> run -c cname params # same as command cname params
> same with alias?
>
> maybe together with some general "whatis" mechanism, that would give
> information about a symbol, its definitions, and the order in which
> they are to be resolved.
Does:
type - a P
list them in order? It seems always to be in the order alias - function -
command.
-- Reuti
Re: 'official function declaration format' doesn't work if alias defined
Hi,
Am 07.01.2016 um 00:49 schrieb Linda Walsh:
> I had an alias referring to printf that I wanted to replace
> with a function.
>
> instead of using the function declarator
> 'function' (or my alias 'sub'), I remembered that the official
> way was to use:
>
> P () {
> ...
> }
>
> But then ran into problems with the alias taking precedence over the
> function.
>
> Even in the file where the function was defined and exported, I got
> an error in the export statement about "P" not being a function.
> I also tried unaliasing it:
>
> unalias P >& /dev/null || ((1))
>
> export -f P Pe
>
> But still got the "not a function" ... then I realized
> I had used the official, POSIX format for function declarations,
> above, but guess it had silently been changed into
> printf () {
> ...
> }
> by the 'alias'.
Yep. You redefined printf().
> Sure enough, using the old form:
>
> function P () {
> ...
> }
>
> caused "P" to be defined as a function -- so when it was
> unaliased and exported, the export statement found the function.
>
> I am not sure how one would catch a problem like that other than
> by make sure the defined function is never the 1st argument on the line
> (by adding function).
Yep, without the "function" keyword the alias will be used also for replacing
the name of the to be defined function:
$ alias P=foo
$ P () { echo baz; }
$ foo
baz
$ type P
P is aliased to `foo'
$ type foo
foo is a function
foo ()
{
echo baz
}
as it's the first word.
> Seems like using 'function' is safer.
>
> Perhaps the idea of leaving off "function" at the beginning of a function
> isn't such a good practice?
Even if you use it: someone could define an alias named function - and this
stands for all commands.
In some cases it might be possible to check the exit code of `alias P` resp.
`type P` beforehand, or to remove with "unalias -a" all aliases.
-- Reuti
Wrong variable expansion inside quotation marks
Hi,
I have one system with:
[EMAIL PROTECTED]:~> bash --version
GNU bash, version 3.00.16(1)-release (i586-suse-linux)
Copyright (C) 2004 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~> hallo=hallo
[EMAIL PROTECTED]:~> rr=r
[EMAIL PROTECTED]:~> tt="${rr:0:${#rr}-1}$hallo"
[EMAIL PROTECTED]:~> echo ${#tt}
5
This is what I expect. But in an newer bash:
[EMAIL PROTECTED]:~$ bash --version
GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~$ hallo=hallo
[EMAIL PROTECTED]:~$ rr=r
[EMAIL PROTECTED]:~$ tt="${rr:0:${#rr}-1}$hallo"
[EMAIL PROTECTED]:~$ echo ${#tt}
6
There is suddenly a 6th illegal character generated (in the original
routine its purpose was to remove the last character of $rr (which is
als at least one character long). But only if rr is one character
long - if it's longer all is fine again.
I circumvent the problem for now by removing the quotation marks:
[EMAIL PROTECTED]:~$ tt=${rr:0:${#rr}-1}$hallo
[EMAIL PROTECTED]:~$ echo ${#tt}
5
-- Reuti
Curly braces expansion not always works as expected.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Date: Thu, 5 Oct 2006 00:19:07 +0200 (CEST)
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin8.0
Compiler: gcc
Compilation CFLAGS: -arch i386 -arch ppc -g -Os -pipe -no-cpp-precomp
- -mdynamic-no-pic -arch i386 -arch ppc -pipe -DPROGRAM='bash'
- -DCONF_HOSTTYPE='powerpc' -DCONF_OSTYPE='darwin8.0' -
DCONF_MACHTYPE='powerpc-apple-darwin8.0' -DCONF_VENDOR='apple' -
DSHELL -DHAVE_C
ONFIG_H -DMACOSX -I. -I/SourceCache/bash/bash-44.2/bash -I/
SourceCache/bash/bash-44.2/bash/include -I/SourceCache/bash/bash-44.2/
bash/lib -arch i386 -arch ppc -g -Os -pipe -no-cpp-precomp -mdynamic-
no-pic -arch i386 -arch ppc -pipe
uname output: Darwin defiant.local 8.8.0 Darwin Kernel Version 8.8.0:
Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_
PPC Power Macintosh powerpc
Machine Type: powerpc-apple-darwin8.0
Bash Version: 2.05b
Patch Level: 0
Release Status: release
Description:
Curly braces expansion only works with at least one comma
(,). This also works, if the appears at least once
inside some apostrophes and has no function.
Repeat-By:
[EMAIL PROTECTED]:~> bash --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Copyright (C) 2002 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~> echo {"x x"} # No {} in output expected.
{x x}
[EMAIL PROTECTED]:~> echo {"xx"} # No {} in output expected.
{xx}
[EMAIL PROTECTED]:~> echo {"xx","yy"} # Works fine.
xx yy
[EMAIL PROTECTED]:~> echo {"x,x"} # Add a comma to get it
working, i.e. remove the {}.
x,x
[EMAIL PROTECTED]:~>
Also this seems to be strange:
[EMAIL PROTECTED]:~> echo {"klklkl"} {1,2,3} # Only second {}
works correctly.
{klklkl} 1 2 3
[EMAIL PROTECTED]:~> echo {"klklkl"}{1,2,3} # Completely messed up.
{klklkl}{1,2,3}
[EMAIL PROTECTED]:~> echo {"kl,klkl"}{1,2,3} # Add a comma to
get it working
kl,klkl1 kl,klkl2 kl,klkl3
[EMAIL PROTECTED]:~>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFJDRxFaaMqfE3kdMRAgrfAKCMejocXoiyIMa+5txJ+hmuPHeNTQCginJY
tnVVdtUPfcBcT8T8RCRTY6k=
=Lbpm
-END PGP SIGNATURE-
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
