RFU: mksh-40c-1
Please upload mksh-40c-1: --- wget -x -nH --cut-dirs=1 \http://emergedesktop.org/cygwin/mksh/mksh-40c-1.tar.bz2 \http://emergedesktop.org/cygwin/mksh/mksh-40c-1-src.tar.bz2 --- Feel free to remove anything older than 40b. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: RFU: mksh-40c-1
On Nov 24 09:18, Chris Sutcliffe wrote: Please upload mksh-40c-1: --- wget -x -nH --cut-dirs=1 \http://emergedesktop.org/cygwin/mksh/mksh-40c-1.tar.bz2 \http://emergedesktop.org/cygwin/mksh/mksh-40c-1-src.tar.bz2 --- Feel free to remove anything older than 40b. Done and done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Cygwin Terminal icon broken on case-sensitive systems
I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. Apparently at least two users have fallen foul of this already: http://georgik.sinusgear.com/2011/11/23/mintty-resizable-terminal-for-windows/ Andy
Re: Cygwin Terminal icon broken on case-sensitive systems
On Nov 24 15:42, Andy Koppe wrote: I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. I don't understand that. See the setup sources, file desktop.cc, line 252: save_icon (/Cygwin-Terminal.ico, CYGWIN-TERMINAL.ICON); And here's what *I* got using the current setup: $ ls -l / total 401 -rw-r--r-- 1 corinna Administrators 53342 Nov 17 10:14 Cygwin-Terminal.ico -rwxr-xr-x 1 corinna Administrators 59 Nov 17 10:14 Cygwin.bat -rw-r--r-- 1 corinna Administrators 157097 Nov 17 10:14 Cygwin.ico [...] How come that the file is created in all lowercase on other systems? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Cygwin Terminal icon broken on case-sensitive systems
On 24 November 2011 15:42, Andy Koppe wrote: I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. Actually, I take it all back. I'd confused myself by still having a 'cygwin-terminal.ico' lying around from earlier experiments. Setup.exe does create it with the correct name. Apparently at least two users have fallen foul of this already: http://georgik.sinusgear.com/2011/11/23/mintty-resizable-terminal-for-windows/ Still leaves the question what's going on there. Andy
winsup/cygwin ChangeLog dcrt0.cc fork.cc pinfo ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-11-24 21:36:53 Modified files: cygwin : ChangeLog dcrt0.cc fork.cc pinfo.cc select.cc sigproc.cc spawn.cc strace.cc cygwin/include/sys: strace.h Log message: * cygthread.h (cygthread::name): Default name to main if we are early in the process of setting up the DLL and no name is known. * dcrt0.cc (initial_env): Remove CYGWIN_SLEEP stuff. (get_cygwin_startup_info): Activate strace here as appropriate. (dll_crt0_0): Move get_cygwin_startup_info as early as possible to avoid missing strace output. * fork.cc (frok::child): Move debugging statement to point where ppid will be set. * pinfo.cc (pinfo::thisproc): Remove obsolete call to strace.hello. Tweak debug output slightly. * select.cc (select_stuff::wait): Allow APCS to be triggered while waiting since we use them now. Report when that happens. * sigproc.cc (child_info::child_info): Use strace.active() rather than strace.attached(). * spawn.cc (child_info_spawn::worker): Only write strace child pid when we know it's a cygwin process. Accommodate change to write_child argument list. * strace.cc (strace::hello): Delete. Move functionality... (strace::activate): ...to here. (mypid): Just use raw GetCurrentProcessId () if myself isn't set. (strace::write_childpid): Don't wait for subproc_ready. Remove arg which was required for it. * include/sys/strace.h (strace::hello): Delete. (strace::write_childpid): Delete first argument. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5566r2=1.5567 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dcrt0.cc.diff?cvsroot=uberbaumr1=1.411r2=1.412 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fork.cc.diff?cvsroot=uberbaumr1=1.228r2=1.229 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.cc.diff?cvsroot=uberbaumr1=1.287r2=1.288 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.177r2=1.178 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.361r2=1.362 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/spawn.cc.diff?cvsroot=uberbaumr1=1.314r2=1.315 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/strace.cc.diff?cvsroot=uberbaumr1=1.74r2=1.75 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/strace.h.diff?cvsroot=uberbaumr1=1.30r2=1.31
winsup/cygwin cygthread.cc ChangeLog
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-11-24 21:38:17 Modified files: cygwin : cygthread.cc ChangeLog Log message: missed this in previous checkin Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygthread.cc.diff?cvsroot=uberbaumr1=1.87r2=1.88 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5567r2=1.5568
winsup/utils ChangeLog strace.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-11-24 21:54:42 Modified files: utils : ChangeLog strace.cc Log message: * strace.cc (attach_process): Use NT_SUCCESS to figure out if NtSetInformationProcess succeeded. (handle_output_debug_string): Put back DebugActiveProcess since it seems to still be needed (on my system at least). Detect new format _STRACE_INTERFACE_ACTIVATE_ADDR which informs whether this is a forked process or not. Use that to decide if forkdebug should be handled. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/utils/ChangeLog.diff?cvsroot=uberbaumr1=1.568r2=1.569 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/utils/strace.cc.diff?cvsroot=uberbaumr1=1.60r2=1.61
Re: chere, mksh and pdksh
On Wednesday, November 23, 2011 8:31 PM, Dave Kilroy kilr...@googlemail.com wrote: On 23/11/2011 08:12, Ronald Fischer wrote: Is there a technical reason, why chere needs to know a predefined set of keys for the shell to install? If I recall, this was to make it simple to locate any entry chere may have created. I thought so. This would go well to allow a path in addition to a key. For instance, would it not be sufficient to pass the path to the shell? In this case, new shells can be installed without the need to update chere. I think it would have to be a munged path. I suspect '/' would not be valid in a key name. Yes, but I don't think this would be a real problem in practice. New shells would depend on the shell conforming to some minimal requirements. If I recall, the existing shells do login shells slightly different. They do the login differently, but this is not something chere needs to worry. Any shell could be invoked by just calling the path (this works from command line). Of course one might argue that the user would want more control on how the shell should be invoked. For instance, I want to choose whether the shell should act as a login shell or as a non-login shell, or whether the -x should be set on invocation. Note that these are features not supported by the current chere, but when we think about expanding the concept, it makes sense thinking about this too. In fact, this could be achieved easily too, in two ways: Either chere allows for a path to the shell AND arguments, which means that the arguments need to be munged in as well; or chere insists in only getting a path to a shell. In the latter case, the user could supply a cover script (say, in bash), which just does an exec to the shell he wants to, supplying the necessary parameters. Also, if I can use the path to the shell as a key, I could (by using appropriate symlinks) have several chere entries for the same shell (for instance, mintty with ksh AND rxvt with ksh). My feeling is that most people have a prefered terminal, but may need to use different shells. The terminals behave in different ways, for example how they react on ANSI escape sequences, so it's handy to be able to run a shell in different terminals. To do what you want, my feeling is that it's easier use what chere does as an example. You can even script it with something like: chere -ip -t mintty -s ksh | sed -e s/cygwin_ksh/mintty_ksh/g a.sh chere -ip -t rxvt -s ksh | sed -e s/cygwin_ksh/rxvt_ksh/g b.sh ./a.sh ./b.sh This is indeed a feasible solution! Good point! Ronald -- Ronald Fischer rona...@eml.cc + If a packet hits a pocket on a socket on a port, + and the bus is interrupted and the interrupt's not caught, + then the socket packet pocket has an error to report. + (cited after Peter van der Linden) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: An AWK-ward problem...
On Nov 23 15:21, Flint, Paul wrote: Greetings List lurkers, I have been troubleshooting some new bash script that I wrote and wanted (for some reason :^) to run on an NT box. So the struggle began... Anyway I get the oddest error: snip /cygdrive/c/Program Files/Git/bin/awk: line 7: $'\r': command not found /cygdrive/c/Program Files/Git/bin/awk: line 7: $'\r': command not found warning: LF will be replaced by CRLF in sendjcl.log. snap So... I check my code and check my code... soon the problem begins to drive me mad... Then! I do this from a cygwin ver 2.761 terminal... $cd /c/cygwin/bin $dos2unix awk Now awk works! I don't believe in this solution: - The above error messages are not Cygwin gawk error messages. They look like bash error messages. Bash doesn't understand CRLF line endings in scripts unless you explicitly allow that. - /cygdrive/c/Program Files/Git/bin/awk is apparently the name of a shell script. /cygdrive/c/Program Files/Git/bin/awk is certainly not /bin/awk. - /bin/awk is a symlink to /bin/gawk.exe, an executable. If you call dos2unix on an executable, the executable will be either unchanged, or broken with a high probability. - Even if it doesn't matter in this scenario, Cygwin's gawk understands CRLF line endings in awk scripts. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Create file fails on network drives in cygwin-1.7.9-1
On Nov 24 15:15, keith-k...@netspace.net.au wrote: I had the same problem, and the suggested solution below worked. Failing a permanent fix, it would be great if a future version of cygwin allowed me to specify (via a config file) that I need to mount (some or all) of the /cygdrive directories with noacl option (or even better - pointers on how to achieve that with the current version). The User's Guide is your friend: http://cygwin.com/cygwin-ug-net/using.html#cygdrive Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: An AWK-ward problem...
On November 24, 2011 10:17 AM Corinna Vinschen wrote: On Nov 23 15:21, Flint, Paul wrote: Greetings List lurkers, I have been troubleshooting some new bash script that I wrote and wanted (for some reason :^) to run on an NT box. So the struggle began... Anyway I get the oddest error: snip /cygdrive/c/Program Files/Git/bin/awk: line 7: $'\r': command not found /cygdrive/c/Program Files/Git/bin/awk: line 7: $'\r': command not found warning: LF will be replaced by CRLF in sendjcl.log. snap So... I check my code and check my code... soon the problem begins to drive me mad... Then! I do this from a cygwin ver 2.761 terminal... $cd /c/cygwin/bin $dos2unix awk Now awk works! I don't believe in this solution: - /cygdrive/c/Program Files/Git/bin/awk is apparently the name of a shell script. /cygdrive/c/Program Files/Git/bin/awk is certainly not /bin/awk. Actually, this looks like you aren’t running cygwin at all. Did you install msys git? That would install a rudimentary set of unix tools compiled with mingw, the default path is exactly as in your error message. Check your path settings. Michael
Re: cygwin dlls needed to run binutils
On 23/11/2011 16:59, Ryan Johnson wrote: On 23/11/2011 11:47 AM, Surrounder wrote: Larry Hall (Cygwin) wrote: A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but perhaps another tool from the package pulls that one in. I found out that the needed dll´s depend on the .\configure I do, is there a way to find out what options were used makeing binutils last time out of the binaries? I tried searching a list where I can maybe find info about what cygwin dll is used for what function in binutils. I suspect that --disable-nls would remove the dependency on libintl, but I don't know what would pull in libz. That'll probably be the support for zip-compressed debug info sections that was added to the mainline sources around this time last year. It can be disabled by passing --with-zlib=no to configure, or apparently also as a side-effect of --disable-nls (according to a quick reading of the configure scripts, I haven't tested.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin dlls needed to run binutils
On 24/11/2011 7:07 AM, Dave Korn wrote: On 23/11/2011 16:59, Ryan Johnson wrote: On 23/11/2011 11:47 AM, Surrounder wrote: Larry Hall (Cygwin) wrote: A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but perhaps another tool from the package pulls that one in. I found out that the needed dll´s depend on the .\configure I do, is there a way to find out what options were used makeing binutils last time out of the binaries? I tried searching a list where I can maybe find info about what cygwin dll is used for what function in binutils. I suspect that --disable-nls would remove the dependency on libintl, but I don't know what would pull in libz. That'll probably be the support for zip-compressed debug info sections that was added to the mainline sources around this time last year. It can be disabled by passing --with-zlib=no to configure, or apparently also as a side-effect of --disable-nls (according to a quick reading of the configure scripts, I haven't tested.) That's weird... why does NLS have anything to do with zip-compressed debug info? Or do they both use zlib and somebody just forgot to update the configure script? Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mksh-40c-1
Version 40c-1 of mksh has been uploaded. MirBSD Korn Shell (mksh) is an actively developed free implementationof the Korn Shell programming language and a successor to the PublicDomain Korn Shell (pdksh). *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, lookat the List-Unsubscribe: tag in the email header of this message.Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read*all* of the information on unsubscribing that isavailable starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
an RFE
Folks, I'd like to issue an RFE: the source download for some packages goes into /usr/src/package name/ many others, however, dump their content straight into /usr/src/ I'd like to propose making the former scheme mandatory. This makes having and keeping up-to-date a local source repository much easier. Dunno whether this would require a change to setup's source or whether this would put a burden on indiv. maintainers to make this happen. Kindly, H. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Machine very sluggish while compiling
Hi all, Lately I've noticed that running make -j4 on my quad-core win7-x64 machine causes it to become sluggish or even unresponsive. For example, compiling a large package makes the mouse jumpy, delays keystrokes, adds stutter to my music, and makes task switching painfully slow (though, oddly, if I manage to switch to the mintty that runs make the machine comes back). The sluggishness always hits when I'm using a native windows app with the compile running in the background. This starts to sound oddly like the recently-reported issue where X was causing native windows apps to freeze [1]. I'm not seeing any fork failures, and am running BLODA-free (Windows Defender hasn't reappeared since I last uninstalled it). There's no unusual disk activity and memory utilization remains stable. I've tried running with nice, reducing the priority of 'make' from the task manager, and running make -j3 to no avail, though empirically if utilization stays at or below 2 cpu then there's no problem. I've compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for several years now and never seen this behavior before. Any ideas of how I might diagnose the issue further? It's easy enough to work around, but compiles take a lot longer with only 1-2 cores instead of 4. Thanks, Ryan [1] http://cygwin.com/ml/cygwin-xfree/2011-11/msg00027.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Machine very sluggish while compiling
Hi Ryan, Ryan Johnson wrote: Lately I've noticed that running make -j4 on my quad-core win7-x64 machine causes it to become sluggish or even unresponsive. For example, compiling a large package makes the mouse jumpy, delays keystrokes, adds stutter to my music, and makes task switching painfully slow (though, oddly, if I manage to switch to the mintty that runs make the machine comes back). The sluggishness always hits when I'm using a native windows app with the compile running in the background. This starts to sound oddly like the recently-reported issue where X was causing native windows apps to freeze [1]. I'm not seeing any fork failures, and am running BLODA-free (Windows Defender hasn't reappeared since I last uninstalled it). There's no unusual disk activity and memory utilization remains stable. I've tried running with nice, reducing the priority of 'make' from the task manager, and running make -j3 to no avail, though empirically if utilization stays at or below 2 cpu then there's no problem. I've compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for several years now and never seen this behavior before. Any ideas of how I might diagnose the issue further? It's easy enough to work around, but compiles take a lot longer with only 1-2 cores instead of 4. I've seen problems like this caused by viruses. Process Explorer might give you more detailed info: http://technet.microsoft.com/en-au/sysinternals/bb896653 Perhaps you are using a different version of bash or other shell? Some versions have been known to bog down the system as you describe. Search for bash slow might yield some clues: http://cygwin.com/ml/cygwin/ -- Regards, Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Machine very sluggish while compiling
On 24/11/2011 11:06 PM, Mike wrote: Hi Ryan, Ryan Johnson wrote: Lately I've noticed that running make -j4 on my quad-core win7-x64 machine causes it to become sluggish or even unresponsive. For example, compiling a large package makes the mouse jumpy, delays keystrokes, adds stutter to my music, and makes task switching painfully slow (though, oddly, if I manage to switch to the mintty that runs make the machine comes back). The sluggishness always hits when I'm using a native windows app with the compile running in the background. This starts to sound oddly like the recently-reported issue where X was causing native windows apps to freeze [1]. I'm not seeing any fork failures, and am running BLODA-free (Windows Defender hasn't reappeared since I last uninstalled it). There's no unusual disk activity and memory utilization remains stable. I've tried running with nice, reducing the priority of 'make' from the task manager, and running make -j3 to no avail, though empirically if utilization stays at or below 2 cpu then there's no problem. I've compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for several years now and never seen this behavior before. Any ideas of how I might diagnose the issue further? It's easy enough to work around, but compiles take a lot longer with only 1-2 cores instead of 4. I've seen problems like this caused by viruses. Process Explorer might give you more detailed info: http://technet.microsoft.com/en-au/sysinternals/bb896653 I've used Process Explorer several times in the past, but it's not immediately obvious to me what I should be using it to look for. Suspicious dlls? I keep my machine patched, regularly check my process list for suspicious/unfamiliar entries, and have not had a virus in roughly 8 years (and that one was thanks to my sister in-law borrowing the machine). I can't rule out a rootkit infection, but PE wouldn't be any help there anyway. Perhaps you are using a different version of bash or other shell? Some versions have been known to bog down the system as you describe. Search for bash slow might yield some clues: http://cygwin.com/ml/cygwin/ Latest version of cygwin's bash, bash-completions package is not installed. Also, make+compilation seems to proceed at normal speed the whole time... it's everybody else that suffers. BTW, thanks for the ideas, they're definitely solid sanity checks. Regards, Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
pl. help
Dear Sir; i want to read the tape drive with cygwin and copy the data to hard disk my below programme is written for linux .pl.hwlp me in converting window base system so that i can read/write and copy data with windows Vista. thanks in advance. value=0 set `date` while [ $value -ne 5 ] do clear tput smso echo DOTWARE AHMEDABAD TELECOMM DISTRICT DATE : $2 $3 $6 tput rmso echo echo echo echo COMPUTER CELL TR-BILL ACTIVITY MENU TIME : $4 echo- echo echo echo echo 1) [5 E S S Stream-0 ] echo echo echo 2) [5 E S S Meter Tape] echo echo 3) [Tranfer File TO TR-BILL ] echo echo 4) [Copy Stream-0 File from IOBAS ] echo echo 5) [Exit ] echo echo echo -nEnter choice 1 - 5 : read choice echo case $choice in 1)clear echo5-ESS stream-0 DAT dump into the Computer : echo cd /home/detail/data dd if=/dev/nst0 of=/home/detail/data/yy conv=ascii dd ibs=1 conv=ascii if=/dev/nst0 of=/home/detail/data/ama echoEnter input-File Name : read x echoEnter Output-File Name : read y mv $x $y read h sleep 2 ;; 2)clear echo5-ESS Meter Tape Converted in to TEXT Format : echo cd /home/detail/data dd ibs=1 if=/dev/nst0 of=/home/detail/data/mul dd if=/dev/nst0 of=/home/detail/data/yy echoEnter input-File Name : read x echoEnter Output-File Name : read y mv $x $y read I ;; 3)clear echo5-ESS transfer to TR-BILL Server : cd /home/detail/data ls -l ftp 10.72.2.173 ;; 4)clear echoCopying Stream-0 File from IOBAS : cd /home/iobas/Cdr_Completed ls -l echoEnter the File Name to be Copied : read l cp /home/iobas/Cdr_Completed/$l /home/detail/data cd /home/detail/data ls -l echoEnter Output File Name: read n mv $l $n ls -l ;; 5)clear exit;; esac done -- sde 5ess bdr -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: mksh-40c-1
Version 40c-1 of mksh has been uploaded. MirBSD Korn Shell (mksh) is an actively developed free implementationof the Korn Shell programming language and a successor to the PublicDomain Korn Shell (pdksh). *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, lookat the List-Unsubscribe: tag in the email header of this message.Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read*all* of the information on unsubscribing that isavailable starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
