-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 -
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
its. 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
g 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
mation 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
> 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:
>>>>
&
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
d 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."
>
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 d
sion 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
>
> N
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 t
> 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
>>&g
# 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
> 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:
>>
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 TI
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
Is there any
preference which one should be used for the bash builtin?
-- Reuti
> 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 li
k ]]; 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
roublesome 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 -
> 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ász
> 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 conte
n 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 s
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...
> }
>
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
>
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
> 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,
>
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
&
MAND 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
-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-
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'
h people can play around with.
Indeed, then it's working too.
Thx -- Reuti
cho "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 h
ink, 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.
-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 defau
e
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_
y 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
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 i
ome/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/l
39 matches
Mail list logo
