Materials Research International - Call for Papers for inaugural Issue

[Materials Sciences Journal]

Materials Research International

Subject : Call for Manuscripts - Materials Research International

About : Materials Research International

The Materials Research International is an international, chargeless, 
peer-reviewed, 
subscription based journal that aims to publish the latest research in the 
field of materials science.Topics include but not limited to Applications such 
as electronics, optics, photonics, opto-electronics, magnetics, sensors, 
catalysts, coatings, adhesives, Computations/Simulations such as theoretical 
physics and chemistry of materials, molecular dynamics simulations, 
Structural properties such as crystal growth and structure analysis, 
structure-defect analysis, ceramics, refractories, Chemical properties such as 
ion exchange, molecular separation, functionalization, catalytic action, sensor 
action, Inorganic materials such as ceramics, layered materials, microporous 
and mesoporous solids, zeolites, silicates, Nanomaterials such as nanotubes, 
nanoparticles, nanowires, quantum dots, nanocrystals, nanomedicine, 
Biomaterials such as biopolymers, biofilms, bioimplants bioMEMS, biosensors, 
cells, tissues and organs, regenerative medicine, Organic materials such as 
organometallic precursors for thin films/ceramics, novel molecular solids and 
synthetic polymers, Electrical properties(metals, alloys, semiconductors, 
superconductors, ionic conductors, electroceramics, dielectrics).

The journal publishes Original Research Articles, Review Articles, Symposia 
or Topical Collections, Spotlights in the field of materials science.

Details regarding journal such as Guidelines for Authors, Key features of 
journal, Ethics and Malpractice Statement, Publication Process, Aims & Scope, 
Publishing Policies, Research Integrity, Periodicity, Manuscript Submission 
Procedure can be found at journal's home page.

Key Features of Materials Research International

- Electronic submission, no postal charges
- DOI will assign to all published articles
- Chargeless E-reprints
- Assures 15 days peer-review process and 15 days for publication after 
acceptance
- International peer-reviewed journal
- Available in Print and Online versions
- Double-blind peer-reviewed
- Publishes original, of high-quality manuscripts
- Chargeless publication

Editorial Board

- Mukul Chandra Paul(INDIA)
- Fang Deng(P. R. China)
- Xiuwen Cheng(P. R. China)
- Kityk I. V(Poland)
- Lik Hong Wee(Belgium)
- Pablo Lopez-Crespo(Spain)
- Miryala Muralidhar(JAPAN)
- Marie-Paule Pileni(France)
- Clement L. Higginbotham(IRELAND)    >>Visit Editorial Board 
Page

The Process of Publishing

Publication process at TAPH is carried out in an absolutely ethical manner. 
We abide by the rules laid down by COPE. We have a systematic approach of 
functioning. 
We have a set of rules that we follow to accept the proposals and convert them 
into publications. All the proposals received by us undergo a rigorous 
assessment 
process, where the experts refine the content prior to publication. Also, our 
experts take proper care to avoid any sort of plagiarism in the content that 
we publish. Once, the experts refine the content, only then the proposals go 
for getting published. Also, we correspond to the authors to keep them updated 
regarding the status of their proposal. Once, the proposal gets converted to 
a publication, we lay it open for the readers in the printed as well as online 
format.

Our Author-Centric Approach

At TAPH, we follow an author-centric approach of functioning. We work 
hand-in-hand 
with our authors to provide the best quality and standards and to make the 
publication process simpler. Supporting our authors in publishing their works 
is one of the major factors in our priority list. We focus on providing 
efficient 
material to our authors and readers. We provide a global platform for the 
publications 
by making them easily available online.

Publication Ethics and Publication Malpractice Statement

The American Publishing House (TAPH) ensures high standards and quality by 
following strict ethical policies and by meticulous peer review. TAPH follows 
the COPE Flowcharts, according to the Code of Conduct of the Committee on 
Publication 
Ethics (COPE), for resolving the suspected malpractice cases. Malpractices 
include practicing plagiarism, data usage frauds, or bogus claims of 
authorship. 
TAPH, henceforth, expects its editors, reviewers, and authors to follow the 
best guidelines on ethical practices.   
    
Read More>>

We sincerely hope you will accept our invitation and will publish your valuable 
research work.

If you have any questions regarding journal or how to submit manuscripts , 
please contact us .


Regards

Akash Chotavia
Manuscript Management Dept.
The American Publishing House
Publisher's Website

If you no longer wish to receive messages of this nature from us in the future,
please Unsubscribe

--

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Takashi Yano]

On Sat, 31 Aug 2019 02:51:34 +0530
Biswapriyo Nath wrote:
> On Friday, August 30, 2019, Takashi Yano  wrote:
> The HPCON isn't a handle. It's a pointer of a struct of three handles. In
> my opinion, I think it's consistent with pty functions in libc. Like in
> forkpty(2) the pid is returned in master side, here HPCON is same.

Then, is it possible to DuplicateHanlde() for three handles in HPCON
to other process which calls ioctl() with new HPCON?

> Q: From which process do you want to access it?

Just a posibility. Some programs may open pty in a process, call
fork(), exit the process and call ioctl in the fork'ed process.

> To know more about the ConPTY internals here are two of my sample program:
> 
> * XConPty: https://github.com/Biswa96/XConPty
> * wslbridge2: https://github.com/Biswa96/wslbridge2/tree/master/rawpty

Oh! Is that your work? I already know XConPty site and I wondered
what is this and how the auther knows such internal things.

-- 
Takashi Yano 

--
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: Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Brian Inglis]

On 2019-08-30 14:59, Stephen Provine wrote:
>> Cygwin command line parsing has to match Unix shell command line processing,
>> like argument splitting, joining within single or double quotes or after a
>> backslash escaped white space characters, globbing, and other actions 
>> normally
>> performed by a shell, when any Cygwin program is invoked from any Windows
>> program e.g. cmd, without those Windows limitations which exclude any use of 
>> a
>> backslash escape character except preceding another or a double quote.

> I guess my assumption was that the "winshell" parameter would be used to 
> determine
> when a Cygwin process is called from a non-Cygwin process and that it would 
> be more
> appropriate to use standard Windows command line processing (as limiting as 
> it may
> be) in that case. Once in the Cygwin environment, calls from one process to 
> another
> should obviously process command lines according to Unix shell rules.

Not being in the same Cygwin process group and lacking the appropriate interface
info indicates that the invoker was not Cygwin.
Cygwin command line file name globs can include any UTF-8 character excluding
forward and backward (for Windows compatibility) oblique slashes and nulls, with
non-Windows supported characters including leading and trailing spaces and dots,
and result in thousands of file name arguments on the command line e.g.

$ echo /var/log/* | wc -lwmcL
  1   66858 2903078 2903078 2903077

shows I need to clean up my /var/log directory as it contains 64K+ files with
names totalling 2234498 chars/bytes, plus 668579 for paths and spaces, plus a
newline terminator.

Some file names with non-Windows supported characters have them converted to the
UTF-16LE BMP PUA by adding xf000, or for characters not supported by non-UTF-8
interface encodings, ^X CAN x18 followed by a BMP UTF-8 sequence, allowing
conversion to UTF-16LE, at the cost of weird characters in the displayed names.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Biswapriyo Nath]

On Friday, August 30, 2019, Takashi Yano  wrote:

> If ioctl(TIOCSWINSZ, ...)
is called from other process, it fails.

The HPCON isn't a handle. It's a pointer of a struct of three handles. In
my opinion, I think it's consistent with pty functions in libc. Like in
forkpty(2) the pid is returned in master side, here HPCON is same.

Q: From which process do you want to access it?

To know more about the ConPTY internals here are two of my sample program:

* XConPty: https://github.com/Biswa96/XConPty
* wslbridge2: https://github.com/Biswa96/wslbridge2/tree/master/rawpty

** Do not use that code in cygwin. It's undocumented. **

Thank you <3

--
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: Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Stephen Provine via cygwin]

> Cygwin command line parsing has to match Unix shell command line processing,
> like argument splitting, joining within single or double quotes or after a
> backslash escaped white space characters, globbing, and other actions normally
> performed by a shell, when any Cygwin program is invoked from any Windows
> program e.g. cmd, without those Windows limitations which exclude any use of a
> backslash escape character except preceding another or a double quote.

I guess my assumption was that the "winshell" parameter would be used to 
determine
when a Cygwin process is called from a non-Cygwin process and that it would be 
more
appropriate to use standard Windows command line processing (as limiting as it 
may
be) in that case. Once in the Cygwin environment, calls from one process to 
another
should obviously process command lines according to Unix shell rules.

--
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

doxygen 1.8.16-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* doxygen-1.8.16-1
* doxygen-doxywizard-1.8.16-1

Doxygen is a documentation system for C++, C, Java, Objective-C, IDL
(Corba and Microsoft flavours) and to some extent PHP, C#, and D.

This is an update to the latest upstream release.  See

  http://www.doxygen.org/changelog.html

for a list of changes since the previous release.

Ken Brown
Cygwin's Doxygen maintainer

[ANNOUNCEMENT] doxygen 1.8.16-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* doxygen-1.8.16-1
* doxygen-doxywizard-1.8.16-1

Doxygen is a documentation system for C++, C, Java, Objective-C, IDL
(Corba and Microsoft flavours) and to some extent PHP, C#, and D.

This is an update to the latest upstream release.  See

  http://www.doxygen.org/changelog.html

for a list of changes since the previous release.

Ken Brown
Cygwin's Doxygen maintainer

--
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: Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Brian Inglis]

On 2019-08-30 13:16, Stephen Provine via cygwin wrote:
> The standard rules for Microsoft command line processing are documented here:
> https://docs.microsoft.com/en-us/previous-versions/17w5ykft(v=vs.85)
> The Cygwin code for command line processing is in dcrt0.cc, function 
> build_argv.
> The behaviors do not match. For instance, given a test.sh script like this:
> #!/bin/bash
> echo $1
> And the following invocation of bash.exe from a Windows command prompt:
> bash.exe test.sh foo\"bar
> The result is:
> foo\bar
> When the expected result is:
> foo"bar
> As a workaround, you can achieve the expected result using:
> bash.exe test.sh "foo\"bar"
> Which is great until you use a language like Go to shell exec the command 
> line, and don't have control over how the command line string is generated 
> from an original set of arguments. See:
> https://github.com/golang/go/blob/master/src/syscall/exec_windows.go#L86
> Go just reverses the Microsoft standard rules in the most efficient manner 
> possible, but those command lines don't parse correctly in Cygwin processes.
> Go implements a pretty definitive command line parsing algorithm as a 
> replacement for the CommandLineToArgv function in shell32.dll:
> 
> https://github.com/golang/go/commit/39c8d2b7faed06b0e91a1ad7906231f53aab45d1
> The behavior here is based on a detailed analysis of what command line 
> parsing "should" be in Windows:
> http://daviddeley.com/autohotkey/parameters/parameters.htm#WINARGV
> It would be very nice if Cygwin followed the same procedure at startup.

Cygwin command line parsing has to match Unix shell command line processing,
like argument splitting, joining within single or double quotes or after a
backslash escaped white space characters, globbing, and other actions normally
performed by a shell, when any Cygwin program is invoked from any Windows
program e.g. cmd, without those Windows limitations which exclude any use of a
backslash escape character except preceding another or a double quote.

Mixing Cygwin and Windows programs is a user choice requiring them to deal with
any interface issues: just use mintty with bash. ;^> It's actually the same
situation as invoking any another Cygwin program which also does some argument
interpretation, from the shell, possibly requiring nested quoting and escaping.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

On Aug 31 03:20, Takashi Yano wrote:
> On Fri, 30 Aug 2019 09:55:23 +0200
> Corinna Vinschen wrote:
> > On Aug 29 22:15, Biswapriyo Nath wrote:
> > > On Thursday, August 29, 2019, Corinna Vinschen 
> > > 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> > > be checked before use? Also what the FIXME says, isn't clear. Any hint?
> > 
> > Yeah, right.  What happens on pre-W10 1809 systems?  They probably
> > crash on TIOCSWINSZ.  See below.
> 
> This code is protected by
> if (getPseudoConsole () && ...
> that is, pseudo console handle is set only if CreatePseudoConsole()
> successes. In pre-W10 1809, since pseudo console handle is not set,
> this code is not reached. However, it is better to check before
> call as you suggest.
> 
> What is meant in FIXME comment:
> ResizePseudoConsole() needs handle to pseudo console. This handle is
> valid only in the process which created it. If ioctl(TIOCSWINSZ, ...)
> is called from other process, it fails. I had tried DuplicateHandle(),
> but it did not work. Therefore, ResizePseudoConsole() is called
> only if ioctl() is called from PTY master process. Similarly,
> ClosePseudoConsole() can work only in the master process.

Ah, that makes sense.

> > > 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't 
> > > be
> > > it easier to get all the pseudo console function pointers in one
> > > constructor?
> > 
> > In terms of GetModuleHandle/GetProcAddress the right thing to do is to
> > use the autoload feature, i.e., add the functions to autoload.cc like
> > this:
> > 
> >   LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
> >   LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
> >   LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)
> > 
> > If the function call returns FALSE with GetLastError() ==
> > ERROR_PROC_NOT_FOUND, then the function is not available.
> > 
> > Takashi, I didn't actually notice the usage of the Windows heap here.
> > The usual method is to use a tls_pbuf buffer, and rather than
> > using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
> > sys_wcstombs.
> > 
> > Also, can you please change the camelback names in class tty_min to
> > underscored writing, e.g., term_codepage rather than TermCodePage?
> 
> OK. I will revised the code followed to your advice.
> 
> First, I would like to fix some bugs and will post a patch.
> Second, I will revise the coding style.
> 
> May I post them as indivisual patches?

That would be great.  Individual patches with each of them fixing just
a single problem are definitely preferrable over bulk patches.  Please
send them to the cygwin-patches mailing list.

>  I also suppose the patch should be against the v9 patch, right?

Well, actually they should be against current git master.  Incidentally
that's your v9 patch ;)


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Stephen Provine via cygwin]

The standard rules for Microsoft command line processing are documented here:

https://docs.microsoft.com/en-us/previous-versions/17w5ykft(v=vs.85)

The Cygwin code for command line processing is in dcrt0.cc, function build_argv.

The behaviors do not match. For instance, given a test.sh script like this:

#!/bin/bash
echo $1

And the following invocation of bash.exe from a Windows command prompt:

bash.exe test.sh foo\"bar

The result is:

foo\bar

When the expected result is:

foo"bar

As a workaround, you can achieve the expected result using:

bash.exe test.sh "foo\"bar"

Which is great until you use a language like Go to shell exec the command line, 
and don't have control over how the command line string is generated from an 
original set of arguments. See:

https://github.com/golang/go/blob/master/src/syscall/exec_windows.go#L86

Go just reverses the Microsoft standard rules in the most efficient manner 
possible, but those command lines don't parse correctly in Cygwin processes.

Go implements a pretty definitive command line parsing algorithm as a 
replacement for the CommandLineToArgv function in shell32.dll:

https://github.com/golang/go/commit/39c8d2b7faed06b0e91a1ad7906231f53aab45d1

The behavior here is based on a detailed analysis of what command line parsing 
"should" be in Windows:

http://daviddeley.com/autohotkey/parameters/parameters.htm#WINARGV

It would be very nice if Cygwin followed the same procedure at startup.

Thanks,
Stephen


--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Takashi Yano]

Hi Biswapriyo and Corinna,

Thank you very much for testing.

On Fri, 30 Aug 2019 09:55:23 +0200
Corinna Vinschen wrote:
> On Aug 29 22:15, Biswapriyo Nath wrote:
> > On Thursday, August 29, 2019, Corinna Vinschen 
> > 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> > be checked before use? Also what the FIXME says, isn't clear. Any hint?
> 
> Yeah, right.  What happens on pre-W10 1809 systems?  They probably
> crash on TIOCSWINSZ.  See below.

This code is protected by
if (getPseudoConsole () && ...
that is, pseudo console handle is set only if CreatePseudoConsole()
successes. In pre-W10 1809, since pseudo console handle is not set,
this code is not reached. However, it is better to check before
call as you suggest.

What is meant in FIXME comment:
ResizePseudoConsole() needs handle to pseudo console. This handle is
valid only in the process which created it. If ioctl(TIOCSWINSZ, ...)
is called from other process, it fails. I had tried DuplicateHandle(),
but it did not work. Therefore, ResizePseudoConsole() is called
only if ioctl() is called from PTY master process. Similarly,
ClosePseudoConsole() can work only in the master process.

> > 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
> > it easier to get all the pseudo console function pointers in one
> > constructor?
> 
> In terms of GetModuleHandle/GetProcAddress the right thing to do is to
> use the autoload feature, i.e., add the functions to autoload.cc like
> this:
> 
>   LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
>   LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
>   LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)
> 
> If the function call returns FALSE with GetLastError() ==
> ERROR_PROC_NOT_FOUND, then the function is not available.
> 
> Takashi, I didn't actually notice the usage of the Windows heap here.
> The usual method is to use a tls_pbuf buffer, and rather than
> using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
> sys_wcstombs.
> 
> Also, can you please change the camelback names in class tty_min to
> underscored writing, e.g., term_codepage rather than TermCodePage?

OK. I will revised the code followed to your advice.

First, I would like to fix some bugs and will post a patch.
Second, I will revise the coding style.

May I post them as indivisual patches? I also suppose the patch should
be against the v9 patch, right?

> > 3. I can't reproduce this issue with exact steps. But when I zoom in/out +
> > resize mintty window + execute cmd.exe in mintty in some random order it
> > crashed. Here is the error:
> > 
> > [main] D:\Cygwin64\bin\bash 1129
> > fhandler_pty_slave::push_to_pcon_screenbuffer: pty0: pcon_attach
> > mismatch?? (0x18035DBD0)
> 
> Takashi?

This most likely is caused by a bug. Now, I am looking into this problem.
I have found the culprit, maybe.

-- 
Takashi Yano 

--
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: Doxygen 1.8.16

[Ken Brown]

On 8/30/2019 12:52 PM, Yaakov Selkowitz wrote:
> On Fri, 2019-08-30 at 12:42 +, Ken Brown wrote:
>> On 8/29/2019 11:34 AM, Yaakov Selkowitz wrote:
>>> On Thu, 2019-08-29 at 14:25 +, Ken Brown wrote:
 On 8/29/2019 8:51 AM, Kptain wrote:
> Is it possible to make available release 1.8.16 of Doxygen as lot of fixes
> have been provided?

 Yes, I'll do that within the next few days.
>>>
>>> When you do, make sure you update your installation first as LLVM/Clang
>>> was just updated, and doxygen is the last package using the old
>>> version.
>>
>> The doxygen build with the latest LLVM fails as follows:
>>
>> CMake Error at CMakeLists.txt:44 (find_package):
>> Found package configuration file:
>>
>>   /usr/lib/cmake/llvm/LLVMConfig.cmake
>>
>> but it set LLVM_FOUND to FALSE so package "LLVM" is considered to be NOT
>> FOUND.  Reason given by package:
>>
>> The following imported targets are referenced, but are missing: 
>> LLVMSupport
>> LLVMCore LLVMScalarOpts LLVMInstCombine LLVMTransformUtils LLVMAnalysis
>> LLVMipo LLVMMC LLVMPasses LLVMLinker LLVMIRReader LLVMBitReader
>> LLVMMCParser LLVMObject LLVMProfileData LLVMTarget LLVMVectorize
>>
>> I don't know much about CMake or LLVM.  Any idea what's going on?
> 
> This may be a symptom of the switch from a single to multiple shared
> libraries.  In /usr/lib/cmake/llvm/LLVMConfig.cmake, could you try
> moving the line which imports LLVMStaticExports up a few lines, just
> above the import of LLVMExports?

That fixed it.  Thanks.

Ken

--
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: Doxygen 1.8.16

[Yaakov Selkowitz]

On Fri, 2019-08-30 at 12:42 +, Ken Brown wrote:
> On 8/29/2019 11:34 AM, Yaakov Selkowitz wrote:
> > On Thu, 2019-08-29 at 14:25 +, Ken Brown wrote:
> > > On 8/29/2019 8:51 AM, Kptain wrote:
> > > > Is it possible to make available release 1.8.16 of Doxygen as lot of 
> > > > fixes
> > > > have been provided?
> > > 
> > > Yes, I'll do that within the next few days.
> > 
> > When you do, make sure you update your installation first as LLVM/Clang
> > was just updated, and doxygen is the last package using the old
> > version.
> 
> The doxygen build with the latest LLVM fails as follows:
> 
> CMake Error at CMakeLists.txt:44 (find_package):
>Found package configuration file:
> 
>  /usr/lib/cmake/llvm/LLVMConfig.cmake
> 
>but it set LLVM_FOUND to FALSE so package "LLVM" is considered to be NOT
>FOUND.  Reason given by package:
> 
>The following imported targets are referenced, but are missing: LLVMSupport
>LLVMCore LLVMScalarOpts LLVMInstCombine LLVMTransformUtils LLVMAnalysis
>LLVMipo LLVMMC LLVMPasses LLVMLinker LLVMIRReader LLVMBitReader
>LLVMMCParser LLVMObject LLVMProfileData LLVMTarget LLVMVectorize
> 
> I don't know much about CMake or LLVM.  Any idea what's going on? 

This may be a symptom of the switch from a single to multiple shared
libraries.  In /usr/lib/cmake/llvm/LLVMConfig.cmake, could you try
moving the line which imports LLVMStaticExports up a few lines, just
above the import of LLVMExports?

--
Yaakov



--
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: Is there no other run-parts in cygwin?

[Brian Inglis]

On 2019-08-30 02:13, Andrey Repin wrote:
> The only run-parts thing I've found comes with busybox.
> Is there no standalone one?

I downloaded it from Cygwin ports years ago - found repos at:

http://ftp.tcrc.edu.tw/Unix/sourceware.org/cygwinports/x86_64/release/debianutils/

http://ftp.nchu.edu.tw/Unix/sourceware.org/cygwinports/x86_64/release/debianutils/

which you can grab all of into /tmp/ with:

$ wget -nv -P /tmp/ -m -np -nH --cut-dirs=5 $REPO

or just the binary with:

$ wget -nv -P /tmp/ $REPO/debianutils-4.4-1.tar.xz

unless you want to grab and stash more of the ports archive.

Download and (if unfamiliar) install with:

$ tar -x -C / -f /tmp/debianutils-4.4-1.tar.xz

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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] emacs 26.3-2

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* emacs-26.3-2
* emacs-common-26.3-2
* emacs-X11-26.3-2
* emacs-w32-26.3-2
* emacs-lucid-26.3-2

[There was an unannounced 26.3-1 available for a short time, but it
was removed because of a packaging error.]

Emacs is a powerful, customizable, self-documenting, modeless text
editor.  Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.

This is an update to the latest upstream release.  Browse the NEWS
file ('C-h n' within emacs) for changes since the last release.

CYGWIN NOTES


1. The emacs, emacs-w32, emacs-X11, and emacs-lucid packages each
   provide an emacs binary.  These are emacs-nox.exe, emacs-w32.exe,
   emacs-X11.exe, and emacs-lucid.exe, respectively, in order of
   increasing priority.  The postinstall scripts create a symlink
   /usr/bin/emacs that resolves to the highest-priority binary that
   you have installed.  Thus the command 'emacs' will start
   emacs-lucid.exe if you've installed the emacs-lucid package;
   otherwise, it will start emacs-X11.exe if you've installed
   emacs-X11; otherwise, it will start emacs-w32.exe if you've
   installed emacs-w32; otherwise, it will start emacs-nox.exe if
   you've installed emacs.  Similar remarks apply to emacsclient.

   You only need to install one of these four packages, but you can
   install more if you want.  If you have installed more than one and
   don't like the default resolution of /usr/bin/emacs, you can run
   one of the /usr/bin/set-emacs-default-*.sh scripts to change it.
   For example,

 /usr/bin/set-emacs-default-w32.sh

   will make /usr/bin/emacs resolve to /usr/bin/emacs-w32.exe,
   regardless of which packages you've installed.

2. The emacs-common package is new.  It contains the files that are
   needed by all four of the binary packages mentioned above.  It also
   contains the elisp source files, which were previously in a
   separate (now obsolete) emacs-el package.

3. Install emacs-X11 if you want to use the X11 GUI with the GTK+
   toolkit.  (This is the default toolkit.)  You can then type
   'emacs&' in an xterm window, and emacs-X11.exe will start in a new
   window.  If you prefer the Lucid toolkit, install emacs-lucid
   instead.

4. Install emacs-w32 if you want to use the native Windows GUI instead
   of X11.

5. If you use the Emacs MH-E library for email, consider installing
   Cygwin's mailutils-mh package.  To use it, put the line

 (load "mailutils-mh")

   in your site-start.el or ~/.emacs file.

6. If you have sshd running and want to be able to run emacs-X11 from
   a remote machine, you need to enable X11 forwarding by adding the
   following line to /etc/sshd_config:

 X11Forwarding yes

   You might also need to have the cygserver service running.

7. The script /usr/bin/make-emacs-shortcut can be used to create a
   shortcut for starting emacs.  See
   /usr/share/doc/emacs/README.Cygwin for details.

Ken Brown
Cygwin's Emacs maintainer

--
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

emacs 26.3-2

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* emacs-26.3-2
* emacs-common-26.3-2
* emacs-X11-26.3-2
* emacs-w32-26.3-2
* emacs-lucid-26.3-2

[There was an unannounced 26.3-1 available for a short time, but it
was removed because of a packaging error.]

Emacs is a powerful, customizable, self-documenting, modeless text
editor.  Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.

This is an update to the latest upstream release.  Browse the NEWS
file ('C-h n' within emacs) for changes since the last release.

CYGWIN NOTES


1. The emacs, emacs-w32, emacs-X11, and emacs-lucid packages each
   provide an emacs binary.  These are emacs-nox.exe, emacs-w32.exe,
   emacs-X11.exe, and emacs-lucid.exe, respectively, in order of
   increasing priority.  The postinstall scripts create a symlink
   /usr/bin/emacs that resolves to the highest-priority binary that
   you have installed.  Thus the command 'emacs' will start
   emacs-lucid.exe if you've installed the emacs-lucid package;
   otherwise, it will start emacs-X11.exe if you've installed
   emacs-X11; otherwise, it will start emacs-w32.exe if you've
   installed emacs-w32; otherwise, it will start emacs-nox.exe if
   you've installed emacs.  Similar remarks apply to emacsclient.

   You only need to install one of these four packages, but you can
   install more if you want.  If you have installed more than one and
   don't like the default resolution of /usr/bin/emacs, you can run
   one of the /usr/bin/set-emacs-default-*.sh scripts to change it.
   For example,

 /usr/bin/set-emacs-default-w32.sh

   will make /usr/bin/emacs resolve to /usr/bin/emacs-w32.exe,
   regardless of which packages you've installed.

2. The emacs-common package is new.  It contains the files that are
   needed by all four of the binary packages mentioned above.  It also
   contains the elisp source files, which were previously in a
   separate (now obsolete) emacs-el package.

3. Install emacs-X11 if you want to use the X11 GUI with the GTK+
   toolkit.  (This is the default toolkit.)  You can then type
   'emacs&' in an xterm window, and emacs-X11.exe will start in a new
   window.  If you prefer the Lucid toolkit, install emacs-lucid
   instead.

4. Install emacs-w32 if you want to use the native Windows GUI instead
   of X11.

5. If you use the Emacs MH-E library for email, consider installing
   Cygwin's mailutils-mh package.  To use it, put the line

 (load "mailutils-mh")

   in your site-start.el or ~/.emacs file.

6. If you have sshd running and want to be able to run emacs-X11 from
   a remote machine, you need to enable X11 forwarding by adding the
   following line to /etc/sshd_config:

 X11Forwarding yes

   You might also need to have the cygserver service running.

7. The script /usr/bin/make-emacs-shortcut can be used to create a
   shortcut for starting emacs.  See
   /usr/share/doc/emacs/README.Cygwin for details.

Ken Brown
Cygwin's Emacs maintainer

[ANNOUNCEMENT] stow 2.3.1-1

[Andrew Schulman via cygwin]

stow 2.3.1-1 is now available in Cygwin. This release has a few bug fixes,
mainly removal of a run-time dependency on the Perl Hash::Merge and
Clone::Choose libraries. See the upstream changelog at
https://git.savannah.gnu.org/cgit/stow.git/tree/NEWS.

Stow manages the installation of local software packages by creating sets
of symlinks from the installed location (e.g. /usr/local) to a stow
directory (e.g. /usr/local/stow/emacs) where the real files live. This
allows you to keep packages separate, while making them appear to be
installed in the same place.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at 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://cygwin.com/lists.html#subscribe-unsubscribe

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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

stow 2.3.1-1

[Andrew Schulman]

stow 2.3.1-1 is now available in Cygwin. This release has a few bug fixes,
mainly removal of a run-time dependency on the Perl Hash::Merge and
Clone::Choose libraries. See the upstream changelog at
https://git.savannah.gnu.org/cgit/stow.git/tree/NEWS.

Stow manages the installation of local software packages by creating sets
of symlinks from the installed location (e.g. /usr/local) to a stow
directory (e.g. /usr/local/stow/emacs) where the real files live. This
allows you to keep packages separate, while making them appear to be
installed in the same place.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at 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://cygwin.com/lists.html#subscribe-unsubscribe

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: bug with grep 3.0.2 in cygwin 3.0.7

[Eliot Moss]

On 8/30/2019 2:12 AM, Brian Inglis wrote:

On 2019-08-29 19:42, Eliot Moss wrote:

On 8/29/2019 3:08 PM, Andrey Repin wrote:

I encounter some problem with grep option -E on cygwin 3.0.7
echo "a^b" | grep "a^b" #answer a^b ie it's OK
but
echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO

That's an expected result of an impossible constraint.

I have to backslash ^ to be OK like : grep -E 'a\^b'

Yes.

Is-it a bug ?

No.

I don't know if all versions of cygwin and grep are concerned.

RTFM, this is regexp basics.

There was a really great answer to this earlier.  I tried an
answer, but was wrong.  One has to read the "fine print" really
carefully.  At first I thought it was a bug, at least in the
documentation, but the meaning of a^b, when ^ is the metacharacter,
is kind of subtle (IMO at least).  It's easy to miss that
subtlety and think that if ^ is not at the beginning of an
expression it will be treated as an ordinary character ...
But my main point is that RTM would be enough; RTFM seemed
to me perhaps a little more rude than necessary.


https://cygwin.com/acronyms/#RTFM exists and has been amusing rather than rude
in our industry for decades, especially in non-native English locales e.g. here
in this list: "Read The Fine Manual"; but RTM for software products is usually
"Release To Manufacturing", from the days when media was produced!


Ok, I relent!  E

--
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: bug with grep 3.0.2 in cygwin 3.0.7

[Jose Isaias Cabrera]

Duncan Roe, on Friday, August 30, 2019 03:47 AM, wrote...
>
> On Thu, Aug 29, 2019 at 09:42:46PM -0400, Eliot Moss wrote:
> > On 8/29/2019 3:08 PM, Andrey Repin wrote:

> > But my main point is that RTM would be enough; RTFM seemed
> > to me perhaps a little more rude than necessary.
> >
> > Regards - EM
> >
> I don't see anything to object to in "Read The Fine Manual" ;)

You know real well what the F in RTFM stands for: Functioning.  And that, my 
friend, is a little too much nowadays for them sensitivity unchallenged folks.  
Just my 102 Dominican cents. :-)

josé

--
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: Altera NIOSII

[cygwinautoreply]

>We have an Engineer having issues with Altera 13.0sp1.  Would you please le=
>t us know if this version will work with Windows 10 64-bit or if an update =
>is required?  Here's the error message he's receiving but he doesn't give u=
>s the online search points he's using:


>"When I try to run the Altera NIOSII command shell, I get the errors below =
>and does not run.  Online search points to this being cause by a Win 10 upd=
>ate.

>Thanks,
>Agustin


>  3 [main] bash 9864 find_fast_cwd: WARNING: Couldn't compute FAST_CWD =
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>  3 [main] bash 7004 child_info_fork::abort: C:\altera\13.0sp1\quartus\=
>bin\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x4B4000=
>0) !=3D child(0x4BD)
>C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource te=
>mporarily unavailable
>  2 [main] bash 12832 child_info_fork::abort: C:\altera\13.0sp1\quartus=
>\bin\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x4B400=
>00) !=3D child(0x4BA)
>C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource te=
>mporarily unavailable
>  1 [main] bash 15176 child_info_fork::abort: C:\altera\13.0sp1\quartus=
>\bin\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x4B400=
>00) !=3D child(0x28B)
>C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource te=
>mporarily unavailable"

>This is not an application we support in IT.

>Any help would be greatly appreciated.


>With best regards,
>Patty Stone

>Siemens Logistics LLC
>Information Technology
>2700 Esters Blvd., Suite 200B
>P.O. Box 613209
>DFW Airport, TX  75261 USA
>Phone:  972-947-7181
>mailto:  patty.st...@siemens.logistics.comtics.com>
>http://www.usa.siemens.com/logistics







https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

--
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

Altera NIOSII

[Stone, Patricia]

We have an Engineer having issues with Altera 13.0sp1.  Would you please let us 
know if this version will work with Windows 10 64-bit or if an update is 
required?  Here's the error message he's receiving but he doesn't give us the 
online search points he's using:


"When I try to run the Altera NIOSII command shell, I get the errors below and 
does not run.  Online search points to this being cause by a Win 10 update.

Thanks,
Agustin


  3 [main] bash 9864 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  3 [main] bash 7004 child_info_fork::abort: 
C:\altera\13.0sp1\quartus\bin\cygwin\bin\cygiconv-2.dll: Loaded to different 
address: parent(0x4B4) != child(0x4BD)
C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource 
temporarily unavailable
  2 [main] bash 12832 child_info_fork::abort: 
C:\altera\13.0sp1\quartus\bin\cygwin\bin\cygiconv-2.dll: Loaded to different 
address: parent(0x4B4) != child(0x4BA)
C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource 
temporarily unavailable
  1 [main] bash 15176 child_info_fork::abort: 
C:\altera\13.0sp1\quartus\bin\cygwin\bin\cygiconv-2.dll: Loaded to different 
address: parent(0x4B4) != child(0x28B)
C:/altera/13.0sp1/nios2eds/nios2_command_shell.sh: fork: retry: Resource 
temporarily unavailable"

This is not an application we support in IT.

Any help would be greatly appreciated.


With best regards,
Patty Stone

Siemens Logistics LLC
Information Technology
2700 Esters Blvd., Suite 200B
P.O. Box 613209
DFW Airport, TX  75261 USA
Phone:  972-947-7181
mailto:  
patty.st...@siemens.logistics.com
http://www.usa.siemens.com/logistics






--
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: Doxygen 1.8.16

[Ken Brown]

On 8/29/2019 11:34 AM, Yaakov Selkowitz wrote:
> On Thu, 2019-08-29 at 14:25 +, Ken Brown wrote:
>> On 8/29/2019 8:51 AM, Kptain wrote:
>>> Is it possible to make available release 1.8.16 of Doxygen as lot of fixes
>>> have been provided?
>>
>> Yes, I'll do that within the next few days.
> 
> When you do, make sure you update your installation first as LLVM/Clang
> was just updated, and doxygen is the last package using the old
> version.

The doxygen build with the latest LLVM fails as follows:

CMake Error at CMakeLists.txt:44 (find_package):
   Found package configuration file:

 /usr/lib/cmake/llvm/LLVMConfig.cmake

   but it set LLVM_FOUND to FALSE so package "LLVM" is considered to be NOT
   FOUND.  Reason given by package:

   The following imported targets are referenced, but are missing: LLVMSupport
   LLVMCore LLVMScalarOpts LLVMInstCombine LLVMTransformUtils LLVMAnalysis
   LLVMipo LLVMMC LLVMPasses LLVMLinker LLVMIRReader LLVMBitReader
   LLVMMCParser LLVMObject LLVMProfileData LLVMTarget LLVMVectorize

I don't know much about CMake or LLVM.  Any idea what's going on?  Here's the 
relevant part of CMakeLists.txt:

if (use_libclang)
set(clang"1" CACHE INTERNAL "used in settings.h")
 find_package(LLVM CONFIG REQUIRED)  <<< line 44
 find_package(Clang CONFIG REQUIRED)
 if (CMAKE_SYSTEM MATCHES "Darwin")
 set(MACOS_VERSION_MIN 10.11)
 endif()
endif()

It was the same for doxygen-1.8.15.

Ken

--
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: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

[Houder]

On Thu, 29 Aug 2019 17:05:41, Houder  wrote:
> On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen  wrote:
[snip]

> > One problem here is, what to do about border cases like
> > 
> >   $ mkdir a\/\/\/
> > 
> > In theory slashes and backslashes should both be treated as dir
> > separators.  Handling a case like this so that all expectations
> > are satisfied is next to impossible, I guess.
> 
> How about dropping Eric's code snippet in winsup/cygwin/dir.cc ?
> 
> Subdirectory 'a' is created. No problem there. Perhaps the patch has
> become superfluous/ redundant over time?
> 
> I have tried different "values" for the path-argument to mkdir, and
> have not found a problem while the code snippet is being skipped.
> 
> What am I missing?

A trailing forward slash in "pathname" is stripped in path_conv::check,

(look for: *--tail = '\0' )

after "pathname" has been normalized in

normalized_posix_path or normalized_win32_path (or both),

before it is fed into conv_to_win32_path.

Tests have shown that Eric's code snippet can be deleted w/o harm.

Counter arguments?

Henri

> -
> Breakpoint 1 at 0x1800548b9: file 
> /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 317.
> Breakpoint 2 at 0x1800548e3: file 
> /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 326.
> (gdb) r
> Starting program: /usr/bin/mkdir 'a\/\/\/'
> [New Thread 1064.0x1a8c]
> [New Thread 1064.0x59c]
> 
> Thread 1 "mkdir" hit Breakpoint 1, mkdir (dir=0x800041320 "a\\/\\/\\/", 
> mode=511)
> at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:317
> 317   if (isdirsep (dir[strlen (dir) - 1]))
> (gdb) j dir.cc:326
> Continuing at 0x1800548e3.
> 
> Thread 1 "mkdir" hit Breakpoint 2, mkdir (dir=0x800041320 "a\\/\\/\\/", 
> mode=511)
> at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:326
> 326   if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW)))
> (gdb) c
> Continuing.
> [Inferior 1 (process 1064) exited normally]
> (gdb) quit
> 
> 64-@@ ls -ld a*
> drwxr-xr-x+ 1 Henri None 0 Aug 29 16:47 a
> 
> =


--
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: Doxygen 1.8.16

[Kptain]

Ok and again Thanks a lot for your support.



--
Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.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

Is there no other run-parts in cygwin?

[Andrey Repin]

Greetings, All!

The only run-parts thing I've found comes with busybox.
Is there no standalone one?


-- 
With best regards,
Andrey Repin
Friday, August 30, 2019 11:13:16

Sorry for my terrible english...


--
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: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...

[Corinna Vinschen]

Eric?


On Aug 29 17:05, Houder wrote:
> On Wed, 28 Aug 2019 16:22:20, Corinna Vinschen  wrote:
> 
> > > As simple as that?
> > >
> > > diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
> > > index b757851d5c7f..747b1582af50 100644
> > > --- a/winsup/cygwin/dir.cc
> > > +++ b/winsup/cygwin/dir.cc
> > > @@ -314,13 +314,13 @@ mkdir (const char *dir, mode_t mode)
> > > set_errno (ENOENT);
> > > __leave;
> > >   }
> > > -  if (isdirsep (dir[strlen (dir) - 1]))
> > > +  if (dir[strlen (dir) - 1] =3D=3D '/')
> > >   {
> > > /* This converts // to /, but since both give EEXIST, we're okay.  */
> > > char *buf;
> > > char *p =3D stpcpy (buf =3D tp.c_get (), dir) - 1;
> > > dir =3D buf;
> > > -   while (p > dir && isdirsep (*p))
> > > +   while (p > dir && *p =3D=3D '/')
> > >   *p-- =3D '\0';
> > >   }
> > >if (!(fh =3D build_fh_name (dir, PC_SYM_NOFOLLOW)))
> > 
> > One problem here is, what to do about border cases like
> > 
> >   $ mkdir a\/\/\/
> > 
> > In theory slashes and backslashes should both be treated as dir
> > separators.  Handling a case like this so that all expectations
> > are satisfied is next to impossible, I guess.
> 
> How about dropping Eric's code snippet in winsup/cygwin/dir.cc ?
> 
> Subdirectory 'a' is created. No problem there. Perhaps the patch has
> become superfluous/ redundant over time?
> 
> I have tried different "values" for the path-argument to mkdir, and
> have not found a problem while the code snippet is being skipped.
> 
> What am I missing?
> 
> Henri
> 
> -
> Breakpoint 1 at 0x1800548b9: file 
> /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 317.
> Breakpoint 2 at 0x1800548e3: file 
> /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc, line 326.
> (gdb) r
> Starting program: /usr/bin/mkdir 'a\/\/\/'
> [New Thread 1064.0x1a8c]
> [New Thread 1064.0x59c]
> 
> Thread 1 "mkdir" hit Breakpoint 1, mkdir (dir=0x800041320 "a\\/\\/\\/", 
> mode=511)
> at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:317
> 317   if (isdirsep (dir[strlen (dir) - 1]))
> (gdb) j dir.cc:326
> Continuing at 0x1800548e3.
> 
> Thread 1 "mkdir" hit Breakpoint 2, mkdir (dir=0x800041320 "a\\/\\/\\/", 
> mode=511)
> at /usr/src/debug/cygwin-3.1.0-0.2/winsup/cygwin/dir.cc:326
> 326   if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW)))
> (gdb) c
> Continuing.
> [Inferior 1 (process 1064) exited normally]
> (gdb) quit
> 
> 64-@@ ls -ld a*
> drwxr-xr-x+ 1 Henri None 0 Aug 29 16:47 a
> 
> =
> 
> 
> --
> 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

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

[CC Takashi]

On Aug 29 22:15, Biswapriyo Nath wrote:
> On Thursday, August 29, 2019, Corinna Vinschen 
> wrote:
> > Support the new pseudo console in PTY. Pseudo console is a new feature
>  in Windows 10 1809, which provides console APIs on virtual terminal.
> 
> Some queries about this specific feature:

Please note that this is very likely not the final version.  I'm
planning for a release end of october or early november so there's
still lots of time to fix issues.  However, this is a great new feature
which needs good testing, that's why we do these test releases.

> 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> be checked before use? Also what the FIXME says, isn't clear. Any hint?

Yeah, right.  What happens on pre-W10 1809 systems?  They probably
crash on TIOCSWINSZ.  See below.

> 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
> it easier to get all the pseudo console function pointers in one
> constructor?

In terms of GetModuleHandle/GetProcAddress the right thing to do is to
use the autoload feature, i.e., add the functions to autoload.cc like
this:

  LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
  LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
  LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)

If the function call returns FALSE with GetLastError() ==
ERROR_PROC_NOT_FOUND, then the function is not available.

Takashi, I didn't actually notice the usage of the Windows heap here.
The usual method is to use a tls_pbuf buffer, and rather than
using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
sys_wcstombs.

Also, can you please change the camelback names in class tty_min to
underscored writing, e.g., term_codepage rather than TermCodePage?

> 2. There are many defined values are added but those are also present in
> mingw-w64 current git repo. For example, ENABLE_VIRTUAL_TERMINAL_PROCESSING.

We can only use what's part of the current w32api-headers package.

> 3. I can't reproduce this issue with exact steps. But when I zoom in/out +
> resize mintty window + execute cmd.exe in mintty in some random order it
> crashed. Here is the error:
> 
> [main] D:\Cygwin64\bin\bash 1129
> fhandler_pty_slave::push_to_pcon_screenbuffer: pty0: pcon_attach
> mismatch?? (0x18035DBD0)

Takashi?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: bug with grep 3.0.2 in cygwin 3.0.7

[Andrey Repin]

Greetings, Eliot Moss!

>>> I encounter some problem with grep option -E on cygwin 3.0.7
>> 
>> 
>>> echo "a^b" | grep "a^b" #answer a^b ie it's OK
>>> but
>>> echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO
>> 
>> That's an expected result of an impossible constraint.
>> 
>>> I have to backslash ^ to be OK like : grep -E 'a\^b'
>> 
>> Yes.
>> 
>>> Is-it a bug ?
>> 
>> No.
>> 
>>> I don't know if all versions of cygwin and grep are concerned.
>> 
>> RTFM, this is regexp basics.

> There was a really great answer to this earlier.  I tried an
> answer, but was wrong.  One has to read the "fine print" really
> carefully.  At first I thought it was a bug, at least in the
> documentation, but the meaning of a^b, when ^ is the metacharacter,
> is kind of subtle (IMO at least).  It's easy to miss that
> subtlety and think that if ^ is not at the beginning of an
> expression it will be treated as an ordinary character ...

> But my main point is that RTM would be enough; RTFM seemed
> to me perhaps a little more rude than necessary.

Adding to the earlier answers (sorry, replying on the road is not efficient),
there's a https://www.regular-expressions.info/
Which contains a great deal of information about RE, their kinds, caveats and
implementations in various languages.


-- 
With best regards,
Andrey Repin
Friday, August 30, 2019 10:42:35

Sorry for my terrible english...


--
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: bug with grep 3.0.2 in cygwin 3.0.7

[Duncan Roe]

On Thu, Aug 29, 2019 at 09:42:46PM -0400, Eliot Moss wrote:
> On 8/29/2019 3:08 PM, Andrey Repin wrote:
> > Greetings, ak...@free.fr!
> >
> > > Hi,
> > > I encounter some problem with grep option -E on cygwin 3.0.7
> >
> >
> > > echo "a^b" | grep "a^b" #answer a^b ie it's OK
> > > but
> > > echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO
> >
> > That's an expected result of an impossible constraint.
> >
> > > I have to backslash ^ to be OK like : grep -E 'a\^b'
> >
> > Yes.
> >
> > > Is-it a bug ?
> >
> > No.
> >
> > > I don't know if all versions of cygwin and grep are concerned.
> >
> > RTFM, this is regexp basics.
>
> There was a really great answer to this earlier.  I tried an
> answer, but was wrong.  One has to read the "fine print" really
> carefully.  At first I thought it was a bug, at least in the
> documentation, but the meaning of a^b, when ^ is the metacharacter,
> is kind of subtle (IMO at least).  It's easy to miss that
> subtlety and think that if ^ is not at the beginning of an
> expression it will be treated as an ordinary character ...
>
> But my main point is that RTM would be enough; RTFM seemed
> to me perhaps a little more rude than necessary.
>
> Regards - EM
>
I don't see anything to object to in "Read The Fine Manual" ;)

Cheers ... Duncan.

--
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: bug with grep 3.0.2 in cygwin 3.0.7

[Brian Inglis]

On 2019-08-29 19:42, Eliot Moss wrote:
> On 8/29/2019 3:08 PM, Andrey Repin wrote:
>>> I encounter some problem with grep option -E on cygwin 3.0.7
>>> echo "a^b" | grep "a^b" #answer a^b ie it's OK
>>> but
>>> echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO
>> That's an expected result of an impossible constraint.
>>> I have to backslash ^ to be OK like : grep -E 'a\^b'
>> Yes.
>>> Is-it a bug ?
>> No.
>>> I don't know if all versions of cygwin and grep are concerned.
>> RTFM, this is regexp basics.
> There was a really great answer to this earlier.  I tried an
> answer, but was wrong.  One has to read the "fine print" really
> carefully.  At first I thought it was a bug, at least in the
> documentation, but the meaning of a^b, when ^ is the metacharacter,
> is kind of subtle (IMO at least).  It's easy to miss that
> subtlety and think that if ^ is not at the beginning of an
> expression it will be treated as an ordinary character ...
> But my main point is that RTM would be enough; RTFM seemed
> to me perhaps a little more rude than necessary.

https://cygwin.com/acronyms/#RTFM exists and has been amusing rather than rude
in our industry for decades, especially in non-native English locales e.g. here
in this list: "Read The Fine Manual"; but RTM for software products is usually
"Release To Manufacturing", from the days when media was produced!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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