Little cygpath improvement request

Little cygpath improvement request

[Andrey Repin]

Greetings, All!

I would like to request a small functional change for cygpath.
In the event of empty given path argument (i.e. `cygpath -ml ""') silently
return an empty result without error message.
This would greatly simplify wrapper scripts.

Sorry if this has been discussed already, google or mailing list search tool
do not bring up any useful results.


-- 
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.02.2014, <22:12>

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: Little cygpath improvement request

[Larry Hall (Cygwin)]

On 2/14/2014 1:22 PM, Andrey Repin wrote:
> Greetings, All!
>
> I would like to request a small functional change for cygpath.
> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
> return an empty result without error message.
> This would greatly simplify wrapper scripts.

Why isn't redirecting the message to /dev/null not sufficient, something
like this (bash syntax)?

cygpath -ml ""  >/dev/null 2&>1


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: Little cygpath improvement request

[Andrey Repin]

Greetings, Larry Hall (Cygwin)!

> On 2/14/2014 1:22 PM, Andrey Repin wrote:
>> Greetings, All!
>>
>> I would like to request a small functional change for cygpath.
>> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
>> return an empty result without error message.
>> This would greatly simplify wrapper scripts.

> Why isn't redirecting the message to /dev/null not sufficient, something
> like this (bash syntax)?

Because it'll require creating a redirection? And this kind of redundant
inserts blurring the code.
Returning a non-zero exit code would suffice for debugging purposes.

> cygpath -ml ""  >/dev/null 2&>1

Err, not > /dev/null !!! :D


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.02.2014, <23:41>

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: Little cygpath improvement request

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Feb 14 23:43, Andrey Repin wrote:
> Greetings, Larry Hall (Cygwin)!
> 
> > On 2/14/2014 1:22 PM, Andrey Repin wrote:
> >> Greetings, All!
> >>
> >> I would like to request a small functional change for cygpath.
> >> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
> >> return an empty result without error message.
> >> This would greatly simplify wrapper scripts.
> 
> > Why isn't redirecting the message to /dev/null not sufficient, something
> > like this (bash syntax)?
> 
> Because it'll require creating a redirection? And this kind of redundant
> inserts blurring the code.
> Returning a non-zero exit code would suffice for debugging purposes.
> 
> > cygpath -ml ""  >/dev/null 2&>1
> 
> Err, not > /dev/null !!! :D

  dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )

?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Little cygpath improvement request

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> I would like to request a small functional change for cygpath.
>> >> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
>> >> return an empty result without error message.
>> >> This would greatly simplify wrapper scripts.
>> 
>> > Why isn't redirecting the message to /dev/null not sufficient, something
>> > like this (bash syntax)?
>> 
>> Because it'll require creating a redirection? And this kind of redundant
>> inserts blurring the code.
>> Returning a non-zero exit code would suffice for debugging purposes.
>> 
>> > cygpath -ml ""  >/dev/null 2&>1
>> 
>> Err, not > /dev/null !!! :D

>   dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )

> ?

I appreciate the effort, bit this even MORE complicating the possible use
case.

Look, I'm asking for simplification without loosing functionality.
If I NEED to check the path for existence, I would write something to the
extent of

NATIVE=$(cygpath -ml "$2")
if [ $? -gt 0 ]; then yell at user; fi

anyway.
But if I (and the program that I would feed it to) don't care (which is often
the case), the message printed from cygpath doesn't add to functionality. 

P.S.
I've tried to rebuild it myself, but hit a roadblock.
While trying to rebuild only winsup/utils, this happens

checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for i686-w64-mingw32-g++... i686-w64-mingw32-g++
configure: creating ./config.status
config.status: creating Makefile
c++wrap -fno-exceptions -fno-rtti -O2 -g -fno-threadsafe-statics -fno-rtti -fno-exceptions -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -c -o cygpath.o /c/dev/sdc1/cygwin/src/winsup/utils/cygpath.cc
make: *** No rule to make target '/c/dev/sdc1/cygwin/build/winsup/cygwin/Makefile', needed by '/c/dev/sdc1/cygwin/build/winsup/cygwin/libcygwin.a'.  Stop.

An attempt to rebuild whole suite crashes more epically.

make[2]: Entering directory '/c/dev/sdc1/cygwin/build/binutils'
gcc -c -I. -I/c/dev/sdc1/cygwin/src/binutils -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -Wno-error /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l: In function 'yylex':
syslex.l:55:2: error: 'yylval' undeclared (first use in this function)
syslex.l:55:2: note: each undeclared identifier is reported only once for each function it appears in
syslex.l:58:16: error: 'NAME' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l:63:10: error: 'NUMBER' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l:72:23: error: 'UNIT' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l:77:28: error: 'TYPE' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l:84:10: error: 'COND' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.l:85:10: error: 'REPEAT' undeclared (first use in this function)
In file included from /c/dev/sdc1/cygwin/src/binutils/syslex_wrap.c:25:0:
syslex.c: In function 'yy_get_next_buffer':
syslex.c:641:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   for ( n = 0; n < max_size && \
                  ^
syslex.c:1175:3: note: in expansion of macro 'YY_INPUT'
   YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
   ^
Makefile:1332: recipe for target 'syslex_wrap.o' failed
make[2]: *** [syslex_wrap.o] Error 1
make[2]: Leaving directory '/c/dev/sdc1/cygwin/build/binutils'
Makefile:3485: recipe for target 'all-binutils' failed
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory '/c/dev/sdc1/cygwin/build'
Makefile:833: recipe for target 'all' failed
make: *** [all] Error 2

I know I'm doing something wrong, but hell if I know, what...


P.P.S.
I've sent a reply with some interesting discoveries to the "new cygwin1"
thread, but it didn't made it to the list, and I did not receive a bounce
either. 
Should I bug cygwin-owner about it? Message-id is 41636493.20140214234111@mtu-net.ru


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 15.02.2014, <20:04>

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: Little cygpath improvement request

[Andrey Repin]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

Greetings, Corinna Vinschen!

> P.S.
> I've tried to rebuild it myself, but hit a roadblock.

Had to get appropriately tired before I realized, what make tried to tell me.

> make: *** No rule to make target
> '/c/dev/sdc1/cygwin/build/winsup/cygwin/Makefile', needed by
> '/c/dev/sdc1/cygwin/build/winsup/cygwin/libcygwin.a'.  Stop. 

Had to rebuild winsup/cygwin first, and newlib before that, before I were able
to build anything in winsup/utils.

Still don't understand, why it doesn't build from the head, but it's
nonessential now, I suppose.

And, I forgot to clarify, this is CVS source tree.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 16.02.2014, <06:16>

Sorry for my terrible english...

[-- Attachment #2: cygpath.patch --]
[-- Type: application/octet-stream, Size: 366 bytes --]

--- src/winsup/utils/cygpath.cc	2013-06-26 17:10:35.000000000 +0400
+++ src/winsup/utils/cygpath.cc	2014-02-15 20:43:43.506625000 +0400
@@ -658,7 +658,7 @@
     {
       if (ignore_flag)
 	return;
-      fprintf (stderr, "%s: can't convert empty path\n", prog_name);
+      // fprintf (stderr, "%s: can't convert empty path\n", prog_name);
       exit (1);
     }
 

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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: Little cygpath improvement request

[m0viefreak]

I'm not exactly sure what you are trying to accomplish with that patch,
but it looks to me as if everything you want is already present:

  cygpath --help

states

  -i, --ignore          ignore missing argument

which outputs nothing if you pass it an empty argument (or even without
any further argument at all).

Isn't that ( cygpath -mli "$possibly_empty_var" ) what you need?

--
m0vie


--
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: Little cygpath improvement request

[Larry Hall (Cygwin)]

On 2/16/2014 12:40 AM, m0viefreak wrote:
> I'm not exactly sure what you are trying to accomplish with that patch,
> but it looks to me as if everything you want is already present:
>
>    cygpath --help
>
> states
>
>    -i, --ignore          ignore missing argument
>
> which outputs nothing if you pass it an empty argument (or even without
> any further argument at all).
>
> Isn't that ( cygpath -mli "$possibly_empty_var" ) what you need?

Well, if you're actually going to look at the existing functionality
of 'cygpath' before jumping into a thread, you're going to take all the
fun out of it for the rest of us. ;-)

Thanks for pointing out the flaw in my original reply and for providing
an answer that I believe Andrey will appreciate.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: Little cygpath improvement request

[Andrey Repin]

Greetings, m0viefreak!

> I'm not exactly sure what you are trying to accomplish with that patch,
> but it looks to me as if everything you want is already present:

>   cygpath --help

> states

>   -i, --ignore          ignore missing argument

With "that patch", this option can be dropped altogether.

> which outputs nothing if you pass it an empty argument (or even without
> any further argument at all).

It provide no information at all in any event (be it missing argument, or
nonexistent path (not like it's checking for existence right now... which only
making situation more complicated)), requiring non-obvious, manually conceived
tests to ensure that the program operates orderly. 

I should also add that the attach was unintended. Got a little mix-up here,
and the file slipped through cracks to the message.

> Isn't that ( cygpath -mli "$possibly_empty_var" ) what you need?

No, I didn't.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 16.02.2014, <10:10>

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: Little cygpath improvement request

[Larry Hall (Cygwin)]

On 2/16/2014 1:21 AM, Andrey Repin wrote:

<snip>

> It provide no information at all in any event (be it missing argument, or
> nonexistent path (not like it's checking for existence right now... which only
> making situation more complicated)), requiring non-obvious, manually conceived
> tests to ensure that the program operates orderly.

I think you're looking for more from cygpath than it's designed to give.
Its intent is to perform direct Windows<->POSIX path conversions using the
mount table and to provide access to some system defined paths in Windows.
That's really it.  It is not meant to validate input or output.  If you have
a use case which requires that only valid paths are input to or output
from cygpath, that does need to be handled upstream or downstream.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: Little cygpath improvement request

[Andrey Repin]

Greetings, Larry Hall (Cygwin)!

>> It provide no information at all in any event (be it missing argument, or
>> nonexistent path (not like it's checking for existence right now... which only
>> making situation more complicated)), requiring non-obvious, manually conceived
>> tests to ensure that the program operates orderly.

> I think you're looking for more from cygpath than it's designed to give.
> Its intent is to perform direct Windows<->POSIX path conversions using the
> mount table and to provide access to some system defined paths in Windows.
> That's really it.  It is not meant to validate input or output.  If you have
> a use case which requires that only valid paths are input to or output
> from cygpath, that does need to be handled upstream or downstream.

I'm really not looking for anything besides what cygpath already do. I'm kind
of satisfied with it's functionality, except may be one bit, but it's outside
the scope of current discussion.
Since I were able to successfully build it on my own, I can play with it as
much, as my time permit.
If it would turn up into something more convincing, than two slashes plugged
into a line of code, I'll get back to the list.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 16.02.2014, <11:17>

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: Little cygpath improvement request

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

On Feb 15 22:57, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> >> I would like to request a small functional change for cygpath.
> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
> >> >> return an empty result without error message.
> >> >> This would greatly simplify wrapper scripts.
> >> 
> >> > Why isn't redirecting the message to /dev/null not sufficient, something
> >> > like this (bash syntax)?
> >> 
> >> Because it'll require creating a redirection? And this kind of redundant
> >> inserts blurring the code.
> >> Returning a non-zero exit code would suffice for debugging purposes.
> >> 
> >> > cygpath -ml ""  >/dev/null 2&>1
> >> 
> >> Err, not > /dev/null !!! :D
> 
> >   dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
> 
> > ?
> 
> I appreciate the effort, bit this even MORE complicating the possible use
> case.
> 
> Look, I'm asking for simplification without loosing functionality.
> If I NEED to check the path for existence, I would write something to the
> extent of

I'm getting a bit puzzled.  If it's only the message you don't want,
then why not just send this message to /dev/null???

  NATIVE=$(cygpath -ml "$2" 2>/dev/null)

> But if I (and the program that I would feed it to) don't care (which is often
> the case), the message printed from cygpath doesn't add to functionality. 
> 
> P.S.
> I've tried to rebuild it myself, but hit a roadblock.
> While trying to rebuild only winsup/utils, this happens

That never works.  Why don't you just fetch the source archive from
the last package and use the cygport file inside?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Little cygpath improvement request

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> >> I would like to request a small functional change for cygpath.
>> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
>> >> >> return an empty result without error message.
>> >> >> This would greatly simplify wrapper scripts.
>> >> 
>> >> > Why isn't redirecting the message to /dev/null not sufficient, something
>> >> > like this (bash syntax)?
>> >> 
>> >> Because it'll require creating a redirection? And this kind of redundant
>> >> inserts blurring the code.
>> >> Returning a non-zero exit code would suffice for debugging purposes.
>> >> 
>> >> > cygpath -ml ""  >/dev/null 2&>1
>> >> 
>> >> Err, not > /dev/null !!! :D
>> 
>> >   dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
>> 
>> > ?
>> 
>> I appreciate the effort, bit this even MORE complicating the possible use
>> case.
>> 
>> Look, I'm asking for simplification without loosing functionality.
>> If I NEED to check the path for existence, I would write something to the
>> extent of

> I'm getting a bit puzzled.  If it's only the message you don't want,
> then why not just send this message to /dev/null???

Because the message serves no purpose in every use case I could think about.
That, aside the fact it needs to create a redirection.

>   NATIVE=$(cygpath -ml "$2" 2>/dev/null)


>> But if I (and the program that I would feed it to) don't care (which is often
>> the case), the message printed from cygpath doesn't add to functionality. 
>> 
>> P.S.
>> I've tried to rebuild it myself, but hit a roadblock.
>> While trying to rebuild only winsup/utils, this happens

> That never works.  Why don't you just fetch the source archive from
> the last package and use the cygport file inside?

Because I'm building Cygwin itself the first time. When my attempt at saving
time in hope it would "just work" failed, I followed FAQ to the letter, but
got nowhere either. The list of required packages to compile it seems to be
right, though. I've eventually succeed.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 16.02.2014, <17:33>

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: Little cygpath improvement request

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Feb 16 18:41, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> >> >> I would like to request a small functional change for cygpath.
> >> >> >> In the event of empty given path argument (i.e. `cygpath -ml ""') silently
> >> >> >> return an empty result without error message.
> >> >> >> This would greatly simplify wrapper scripts.
> >> >> 
> >> >> > Why isn't redirecting the message to /dev/null not sufficient, something
> >> >> > like this (bash syntax)?
> >> >> 
> >> >> Because it'll require creating a redirection? And this kind of redundant
> >> >> inserts blurring the code.
> >> >> Returning a non-zero exit code would suffice for debugging purposes.
> >> >> 
> >> >> > cygpath -ml ""  >/dev/null 2&>1
> >> >> 
> >> >> Err, not > /dev/null !!! :D
> >> 
> >> >   dos_path=$( [ -n "${posix_path}" ] && cygpath -ml "${posix_path}" )
> >> 
> >> > ?
> >> 
> >> I appreciate the effort, bit this even MORE complicating the possible use
> >> case.
> >> 
> >> Look, I'm asking for simplification without loosing functionality.
> >> If I NEED to check the path for existence, I would write something to the
> >> extent of
> 
> > I'm getting a bit puzzled.  If it's only the message you don't want,
> > then why not just send this message to /dev/null???
> 
> Because the message serves no purpose in every use case I could think about.
> That, aside the fact it needs to create a redirection.
> 
> >   NATIVE=$(cygpath -ml "$2" 2>/dev/null)

And what's the problem with redirections?

I fail to see the big difference between adding a redirection
compared to adding an option character.


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Little cygpath improvement request

[Buchbinder, Barry (NIH/NIAID) [E]]

Corinna Vinschen sent the following at Sunday, February 16, 2014 10:11 AM
>> >   NATIVE=$(cygpath -ml "$2" 2>/dev/null)
>
>And what's the problem with redirections?
>
>I fail to see the big difference between adding a redirection compared
>to adding an option character.

Some of us avoid redirections because we do it so rarely that getting it
correct becomes a long experimental process.

But as an alternative to redirection, one can test for an empty path.

if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: Little cygpath improvement request

[Steven Penny]

On Sun, Feb 16, 2014 at 12:30 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote
> if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi

That might better be written as this

    [ "$2" ] && NATIVE=$(cygpath -ml "$2")

You do not need the extra quotes when setting a variable in this way.

--
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: Little cygpath improvement request

[Andy Hall]

> 
> On Sun, Feb 16, 2014 at 12:30 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote
> > if [ ! -z "$2" ] ; then NATIVE="$(cygpath -ml "$2")" ; fi
> 
> That might better be written as this
> 
>     [ "$2" ] && NATIVE=$(cygpath -ml "$2")
> 
> You do not need the extra quotes when setting a variable in this way.
> 
Goodness. If code cleanliness is the issue, Why not simply hide this construct in a function?

function dospath() {
        [ "$1" ] && cygpath -ml "$1"
}

Then 

NATIVE=$(dospath $1)

Which is about as simple and clear as it gets.


--
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: Little cygpath improvement request

[Steven Penny]

On Sun, Feb 16, 2014 at 7:07 PM, Andy Hall wrote
> Goodness. If code cleanliness is the issue, Why not simply hide this construct
> in a function?

Really this whole thread is a joke. He needs to just

    cygpath -ml "$2" &>/dev/null

as others have said and be done with it.

--
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: Little cygpath improvement request

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > I'm getting a bit puzzled.  If it's only the message you don't want,
>> > then why not just send this message to /dev/null???
>> 
>> Because the message serves no purpose in every use case I could think about.
>> That, aside the fact it needs to create a redirection.
>> 
>> >   NATIVE=$(cygpath -ml "$2" 2>/dev/null)

> And what's the problem with redirections?

> I fail to see the big difference between adding a redirection
> compared to adding an option character.

I think we're nearing the border of the forest here. (The one that you can't
see behind trees.)

I understand that you see no problem in doing additional work at creating a
redirection, because computers are so powerful nowadays, resources are so
plentiful, nobody care... but I, myself, prefer the "it's just works" approach
when it comes to program development. Or in other words, "sensible defaults
are better, than a lot of options."

In this case, I'm in for removing the message AND option as both are redundant.

P.S.
And it's not the first time I'm fighting the case of expected usage pattern
against real-life applications.
The message is "generally useful", but such case is from artificial breed of
generic cases, that does not survive in the wild.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 16.02.2014, <22:25>

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