$>declare MYSTERY_CMD=$(which mystery) && echo "All set." || echo "Adding
to missing array ... "
All set.
$>MYSTERY2_CMD=$(which mystery2) && echo "All set." || echo "Adding to
missing array ... "
Adding to missing array ...
Declaring a variable doesn't seem risky enough to eat up the return code
*Configuration Information [Automatically generated, do not
change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -f$uname output: Linux
amdubuntu 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05$Machine Type:
x86_64-pc-linux-gn
It seems the parameter for the delimiter for the read built-in behaves
differently for the NULL case, and it is a very useful case. I found this
after a difficult to track down bug appeared in some of my code, so I
thought I would pass it on to you.
If it is expected behavior I didn't see it in t
> > Other shells must go out of their way to suppress it, then.
>
> Most of the other shells remove NUL bytes from `read's input. They
> probably do this before checking the delimiter.
Bash also removes the single quotes before it hits read when the single
quotes are attached to the delimiter op
--> -d ''
On Tue, Jan 19, 2016 at 11:49 AM, Greg Wooledge wrote:
> 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'&#
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##*=}, o
On Tue, Mar 22, 2016 at 10:47 AM, Adam Danischewski <
adam.danischew...@gmail.com> wrote:
> 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
> #!/
=50 ## No one can know about.
VAR+=${1}
echo $VAR
}
$ update 0
45
$ update TOPSECRET_NUMBER
95
## Successfully deduce that TOPSECRET_NUMBER is 50
## Instead could be CC_NUM, CCARD, SessionID, CrToken, etc.
On Tue, Mar 22, 2016 at 11:18 AM, Chet Ramey wrote:
> On 3/22/16 10:47 AM, A
I'm not sure if this is a bug, or a feature but I had to debug some code as
a result so I'd like to bring it to your attention, and if you know of a
better way to read from pipes please let me know.
#!/bin/bash
numstr=${1}
rdlnk=$(readlink /proc/$$/fd/0)
function get_input() {
## echo "PID: $$, P
I was expecting it to be the pts.
On Tue, Aug 23, 2016 at 4:58 PM, Chet Ramey wrote:
> On 8/23/16 2:28 PM, Adam Danischewski wrote:
> > I'm not sure if this is a bug, or a feature but I had to debug some code
> as
> > a result so I'd like to bring it to your att
he Solaris Bash code and Linux Bash code.
On Wed, Aug 24, 2016 at 2:09 PM, Chet Ramey wrote:
> On 8/24/16 12:09 PM, Adam Danischewski wrote:
> > I was expecting it to be the pts.
>
> OK. That's just not how it works.
>
>
> --
> ``The lyf so short, the craft so long
ss to
short-circuit.
On Wed, Aug 24, 2016 at 2:52 PM, Adam Danischewski <
adam.danischew...@gmail.com> wrote:
> Let's put aside the fs type for second and talk about what data should be
> there and what should and shouldn't happen.
>
> When a parent script kicks off a chi
$ ls -al
/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3
lrwxrwxrwx 1 cronkilla cronkilla 74 Apr 29 19:30
/mnt/samsung32/.word_list_repo/instruments_song_repo/546725_pinstripe.mp3
->
/mnt/samsung32/.word_list_repo/master_song_repo/0/4/5/546725_pinstripe.mp3
$ [[ -L
"/mnt/s
13 matches
Mail list logo
