Re: [ast-users] Regression in += operator
it looks like an eval problem, the following version does work as desired: ksh93u -c 'typeset -i x=1; (x+=1 eval echo \$x);echo $x' 2 1 Mit freundlichen Gruessen / Best Regards Axel PHILIPP -Ursprüngliche Nachricht- Von: ast-users-boun...@lists.research.att.com [mailto:ast-users-boun...@lists.research.att.com] Im Auftrag von David Korn Gesendet: Mittwoch, 24. Juli 2013 17:44 An: ast-users@lists.research.att.com; orm...@gmail.com Betreff: Re: [ast-users] Regression in += operator [...] If I run $ ksh93u -c 'typeset -i x=1; x+=1 command eval echo \$x;echo $x' 2 2 which is not correct since regular command should not leave side effects in the current environment. I haven't yet decided how to resolved this. David Korn d...@research.att.com ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users -- MTU Aero Engines AG Geschaeftsfuehrung/Board of Management: Egon W. Behle, Vorsitzender/CEO; Dr. Rainer Martens, Michael Schreyögg, Dr. Stefan Weingartner, Reiner Winkler Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Klaus Eberhardt Sitz der Gesellschaft/Registered Office: Muenchen Handelsregister/Commercial Register: Muenchen HRB 157206 Diese E-Mail sowie ihre Anhaenge enthalten MTU-eigene vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte den Absender und loeschen Sie diese E-Mail sowie die Anhaenge. Das unbefugte Speichern, Kopieren oder Weiterleiten ist nicht gestattet. This e-mail and any attached documents are proprietary to MTU, confidential or protected by law. If you are not the intended recipient, please advise the sender and delete this message and its attachments. Any unauthorised storing, copying or distribution is prohibited. ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Problems with (( !b ... )) and bools...
cc: ast-us...@research.att.com Subject: Re: Problems with (( !b ... )) and bools... Hi! The following example prints the wrong boolean value with ast-ksh.2013-07-19 on SuSE 12.3/AMD64/64bit: -- snip -- $ ./arch/linux.i386-64/bin/ksh -c 'bool b=true ; (( b=(!b)?(!false):(!true) )) ; printf %s\n $b' true -- snip -- AFAIK it should print false ... Bye, Roland -- true and false are not constants so there is no meaning to true and false unless you create varibles true and false and define them as 1 and 0. bool is an enumeration contain the enumeration constants true and false. This is no different than enum Color=(red green blue yellow) There is no meaning to !blue inside an arithmetic expression except to do ! blue where blue is a variable. The only operators that recognize enumeriation constants are == != and = when the left hand size is an enumeration variable. My patch allowed enum_var = expr?var1:var2 to recognize var1 and var2 as possible enumeration constants, but it does not recognize !var1. David Korn d...@research.att.com ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Regression in += operator
sorry, I didn't read the man page carefully enough. Because command had no influence, I simply omitted it. However - with command - the effect is the same: home /bin/ksh -c 'AUX=aux command eval echo \$AUX; echo AUX=$AUX' aux AUX=aux home /bin/ksh -c 'AUX=aux command typeset -p AUX ; echo AUX=$AUX' AUX=aux AUX=aux -Ursprüngliche Nachricht- Von: PHILIPP, Axel, Dr. Gesendet: Donnerstag, 25. Juli 2013 13:57 The side effects apply to var=value assignments in front of eval or typeset commands as well: home /bin/ksh -c 'AUX=aux eval echo \$AUX; echo AUX=$AUX' aux AUX=aux home /bin/ksh -c 'AUX=aux typeset -p AUX ; echo AUX=$AUX' AUX=aux AUX=aux home /bin/bash -c 'AUX=aux eval echo \$AUX; echo AUX=$AUX' aux AUX= home /bin/bash -c 'AUX=aux typeset -p AUX ; echo AUX=$AUX' declare -x AUX=aux AUX= home Version AJM 93u+ 2012-08-01 Mit freundlichen Gruessen / Best Regards Axel PHILIPP -Ursprüngliche Nachricht- Von: ast-users-boun...@lists.research.att.com [mailto:ast-users-boun...@lists.research.att.com] Im Auftrag von David Korn Gesendet: Mittwoch, 24. Juli 2013 17:44 [...] It worked in ksh93u but it was leaving side effects and this violated the standard. When I run this in bash, I get $ bash -c 'typeset -i x=1; x+=1 command eval echo \$x' 1 If I run $ ksh93u -c 'typeset -i x=1; x+=1 command eval echo \$x;echo $x' 2 2 which is not correct since regular command should not leave side effects in the current environment. I haven't yet decided how to resolved this. David Korn d...@research.att.com ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users -- MTU Aero Engines AG Geschaeftsfuehrung/Board of Management: Egon W. Behle, Vorsitzender/CEO; Dr. Rainer Martens, Michael Schreyögg, Dr. Stefan Weingartner, Reiner Winkler Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Klaus Eberhardt Sitz der Gesellschaft/Registered Office: Muenchen Handelsregister/Commercial Register: Muenchen HRB 157206 Diese E-Mail sowie ihre Anhaenge enthalten MTU-eigene vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte den Absender und loeschen Sie diese E-Mail sowie die Anhaenge. Das unbefugte Speichern, Kopieren oder Weiterleiten ist nicht gestattet. This e-mail and any attached documents are proprietary to MTU, confidential or protected by law. If you are not the intended recipient, please advise the sender and delete this message and its attachments. Any unauthorised storing, copying or distribution is prohibited. ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Regression in += operator
Subject: Re: Re: [ast-users] Regression in += operator /bin/ksh -c 'AUX=aux command eval echo \$AUX; echo AUX=$AUX' sorry, I didn't read the man page carefully enough. Because command had no inf luence, I simply omitted it. However - with command - the effect is the same: Command has the effect of removing the requirement for a special builtin to keep environment setting in effect after the command completes. David Korn d...@research.att.com ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
[ast-users] Possible problem/question with ^I expansion in emacs mode
The ^I file expansion in emacs mode is documented on ksh(1) as, If a partial completion occurs, repeating this will behave as if M-= were entered. I would think that if ^I is typed a second time after intervening characters it should continue with its original behavior of file expansion of rather than its repeating behavior of listing matches. For example: == $ echo $KSH_VERSION Version AJM 93u+ 2012-08-01 $ set -o emacs $ ls /tmp/mydir/JHS* /tmp/mydir/JHS_REFRESH-10.txt /tmp/mydir/JHS_REFRESH-6.txt /tmp/mydir/JHS_REFRESH-12.txt /tmp/mydir/JHS_REFRESH-9.txt $ ls /tmp/mydir/JHS^I The ^I expands the line to: $ ls /tmp/mydir/JHS_REFRESH- After the expansion immediately type 12 and press ^I again: $ ls /tmp/mydir/JHS_REFRESH-12^I 1) JHS_REFRESH-12.txt $ ls /tmp/mydir/JHS_REFRESH-12 == I would expect that typing the 12 characters would reset the ^I behavior back to file expansion rather than file list. Is this a bug or a correctly operating feature? Quentin ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Ksh build failure with RHEL6.4
Hi Quentin, how did you try to compile it? What version exactly? Do you have experience with compiling ksh or is this your first attempt? Do you have ksh installed in your build environment? What version? I just tried to compile ksh 2013-07-19 on RHEL-6.4 x86_64 and it completed just fine. There was similar error once (with ksh 2013-05-24), but it's fixed already. Michal On 07/25/2013 06:02 PM, Quentin Barnes wrote: I downloaded the current ast-ksh source with bin/package and attempted to build it on a RHEL6.4 x86_64 box. The shcomp and ksh binaries fail to link due to failing to link against libdl and libm. Adding -ldl -lm manually to the link lines of course work. Has anyone reported this problem or a patch in the works that corrects the drop of these libraries? I've made the build log available via pastebin. I had to split into two files since combined it's just slightly over the 500K limit: http://pastebin.com/twq5tK6e // ksh build failure on RHEL6.4 (part 1) http://pastebin.com/8SfcrxBA // ksh build failure on RHEL6.4 (part 2) Quentin ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Edit 10GB file with fixed size records
On 24 July 2013 22:57, Janis Papanagnou janis_papanag...@hotmail.com wrote:
Does ksh have an API to edit a file at a specific position pos1, read
n1 bytes, and write n1 bytes at that position without truncating the
file? I need this to do edit a file in place without reading and
writing it completely each time.
Yes, ksh has seek redirection operators.
Here's an ad hoc example (not sure whether the features are
applied proficiently, but it seems to work :-)
f=somefile
cat EOT $f
Hello world!
My good friend.
How are you?
EOT
function fun ## palindrome (just for example)
{
arg=$1 x=
(( len=${#arg} ))
for ((i=0; ilen; i++))
do res=${arg:i:1}$res
done
printf %s $res
}
pos1=18
n1=8
read -N $n1 content 0$f #((pos1))
printf %s $(fun $content) 1$f #((pos1))
Outputs:
Hello world!
My goneirf dod.
How are you?
Hope it's of some use to you.
How would this example look like if I opened a file descriptor with
the number 19? ksh seems to use file descriptors 0-9 for manual usage,
but descriptors opened with exec {filed}name.rec use numbers 10.
Tina
--
Tina Harriott - Women in Mathematics
Contact: tina.harriott.mathemat...@gmail.com
___
ast-users mailing list
ast-users@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Possible problem/question with ^I expansion in emacs mode
Apparently the twist to this bug is that numerics have to be typed to trigger the bug. If non-numeric characters are typed then ^I, the ^I expands as expected. On Thu, Jul 25, 2013 at 10:47 AM, Quentin Barnes qbar...@gmail.com wrote: The ^I file expansion in emacs mode is documented on ksh(1) as, If a partial completion occurs, repeating this will behave as if M-= were entered. I would think that if ^I is typed a second time after intervening characters it should continue with its original behavior of file expansion of rather than its repeating behavior of listing matches. For example: == $ echo $KSH_VERSION Version AJM 93u+ 2012-08-01 $ set -o emacs $ ls /tmp/mydir/JHS* /tmp/mydir/JHS_REFRESH-10.txt /tmp/mydir/JHS_REFRESH-6.txt /tmp/mydir/JHS_REFRESH-12.txt /tmp/mydir/JHS_REFRESH-9.txt $ ls /tmp/mydir/JHS^I The ^I expands the line to: $ ls /tmp/mydir/JHS_REFRESH- After the expansion immediately type 12 and press ^I again: $ ls /tmp/mydir/JHS_REFRESH-12^I 1) JHS_REFRESH-12.txt $ ls /tmp/mydir/JHS_REFRESH-12 == I would expect that typing the 12 characters would reset the ^I behavior back to file expansion rather than file list. Is this a bug or a correctly operating feature? Quentin ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] Problems with (( !b ... )) and bools...
cc: ast-us...@research.att.com roland.ma...@nrubsig.org Subject: Re: Re: [ast-users] Problems with (( !b ... )) and bools... On 25 July 2013 15:44, David Korn d...@research.att.com wrote: cc: ast-us...@research.att.com Subject: Re: Problems with (( !b ... )) and bools... Hi! The following example prints the wrong boolean value with ast-ksh.2013-07-19 on SuSE 12.3/AMD64/64bit: -- snip -- $ ./arch/linux.i386-64/bin/ksh -c 'bool b=true ; (( b=(!b)?(!false):(!true) )) ; printf %s\n $b' true -- snip -- AFAIK it should print false ... Bye, Roland true and false are not constants so there is no meaning to true and false unless you create varibles true and false and define them as 1 and 0. bool is an enumeration contain the enumeration constants true and false. This is no different than enum Color=(red green blue yellow) How can I access the integer value of a enum? Is integer i; (( i=Color.green )) valid? There is no meaning to !blue inside an arithmetic expression except to do ! blue where blue is a variable. David, I think you are wrong. First, assuming that ksh arithmetic expressions work like ANSI C arithmetic expressions a bool from stdbool.h is still of type bool if the negation (!) operator has been applied, i.e. the result of !b is still of type bool. Second, as the result of !b is of type bool, shouldn't be b=!true a valid expression? The only operators that recognize enumeriation constants are == != and = when the left hand size is an enumeration variable. My patch allowed enum_var = expr?var1:var2 to recognize var1 and var2 as possible enumeration constants, but it does not recognize !var1. Why are enumerations handled special? Can the ksh arithmetic expression engine not just take their integer value? Wendy In C, with stdbool.h true and false are constants. In ksh, true and false are valid variable names. bool is an enumeration consisting of enumeration constants true and false. In C you can't do int false=5; In shell you can do integer false=5. The shell recognizes enumeriation constants are with operators == != and = only. If I make it compatible with C, then any script that uses true and false as variables would break and violate the C standard. David Korn d...@research.att.com ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
