*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
$>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
$ 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
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
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
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
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
=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
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
> #!/
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
--> -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'&#
> > 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
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
13 matches
Mail list logo
