Auto-tiling Textures

[jim]

Hi fridger,

Yes I use an "Windows"-editor (not notepad or MS) and I've chosen UNIX by the Cygwin installation. But with the Bash-shell works all expect the 'identify'-line. Now I've addapted the script to my need (input/output format and tilesize fixed, east/west removed )

'Usage: vt [--help | <texture name> <texturesize> <x0> <y0>]'

where x0, y0 is the start tile ( tx_xO_y0 ).

Now I would change some more. Can you recommend a site where I can find more about this script language? Some file commands like build folder or read all files of a folder and general infos about the syntax would be very usefull.

Bye Jens

[jamarsa]

Here is the zsh Homepage:

http://sunsite.auc.dk/zsh/

and here is a page with (perhaps) useful links:
http://angg.twu.net/zsh.html

If you want to learn bash instead, you can look here:

http://www.gnu.org/software/bash/bash.html

And it is possible, but I'm not certain, that you can consult the manual under Cygwin:

Code: Select all

# man zsh

zsh and bash are mainly command shells, just like the DOS one (BTW, just 'poorly cloned' from the original UNIX sh, we should inform SCO's McBride of this). The Script language is one of the features. To create folders, you just call the correct command ( mkdir under Unixes, md in MS systems). For selecting files in a folder, use wildcards

[t00fri]

Hi fridger,

Yes I use an "Windows"-editor (not notepad or MS) and I've chosen UNIX by the Cygwin installation. But with the Bash-shell works all expect the 'identify'-line. Now I've addapted the script to my need (input/output format and tilesize fixed, east/west removed )

'Usage: vt [--help | <texture name> <texturesize> <x0> <y0>]'

where x0, y0 is the start tile ( tx_xO_y0 ).

Now I would change some more. Can you recommend a site where I can find more about this script language? Some file commands like build folder or read all files of a folder and general infos about the syntax would be very usefull.

Bye Jens

Jens,

since I know UNIX almost as long as I can walk;-) I would strongly recommend NOT to mix line-endings in whatever you are doing! You should not forget that both zsh and bash are highly complex shells with very sophisticated expansion rules etc. It may well be that certain simple things apparently work with your "mixed editing" but with more complicated commands you may eventually be busy forever looking for the reasons of malfunctioning!!

As a first evidence for what I am saying, 'identify' works perfectly well in my consistent Cygwin environment with \LF endings throughout! Be warned....

Bye Fridger

[jamarsa]

since I know UNIX almost as long as I can walk;-) I would strongly recommend NOT to mix line-endings in whatever you are doing! You should not forget that both zsh and bash are highly complex shells with very sophisticated expansion rules etc.

Well, not so sophisticate and complex to don't forgive Windows 'redundant' line endings...

[t00fri]

since I know UNIX almost as long as I can walk;-) I would strongly recommend NOT to mix line-endings in whatever you are doing! You should not forget that both zsh and bash are highly complex shells with very sophisticated expansion rules etc.

Well, not so sophisticate and complex to don't forgive Windows 'redundant' line endings...

Javier,

wait. The source code for zsh and bash in Cygwin is ~ the standard UNIX code. It has never been designed to work in Windows. The cygwin UNIX emulation allows once for all a selection to choose either DOS or UNIX line endings but not both. This is a special Cygwin feature. Has nothing to do with the zsh or bash code. As you know, UNIX has a long and Bill-Gates-independent history. It's not at all a matter of forgiving BG's line endings;-). I know zsh and bash grammar forward and backward since more than 10-15 years. It is sophisticated!;-)

Bye Fridger

[jamarsa]

Yes, I know. Just making a joke...

I have also worked in Unix, sh & derivatives for more than 18 years. But as current shells are written&maintained in the days of Windows dominance, most of them are aware of the windows quirks. I specially expect that in Cygwin, since it's designed to work in a Windows environment!!


I'm not saying that zsh isn't sophisticated, I know very well that I can do things in zsh that are totally impossible in Windows unless you buy a compiler!!!

[t00fri]

Yes, I know. Just making a joke...
...
But as current shells are writtend in the days of Windows dominance, most of them are aware of the windows quirks.
...

Oh, that's interesting. Which shells are you refering to that can digest scripts or commands with \CR's thrown in at
arbitrary places with line endings being sometimes \LF and sometimes \CR\LF??

The Cygwin bash apparently also has also a problem, since 'identify' does not seem to work, if virtualtex is edited with a Windows editor...

Thinking more about this issue, I guess I could construct ambiguous cases that advanced shells would be unable to decide in principle!

Bye Fridger

[jim]

Hi Fridger,

Sorry I really don't know that there is a difference between DOS and UNIX text files. Yesterday I compared with an hex editor two files an could see the different line endings. Do you know an windows editor that can save files in UNIX format?

Bye Jens

[jamarsa]

Oh, that's interesting. Which shells are you refering to that can digest scripts or commands with \CR's thrown in at
arbitrary places with line endings being sometimes \LF and sometimes \CR\LF??

What's the problem in treating them, when not quoted, just as

separators, like spaces, tabs, linefeeds...? This could be a customizable option, for example:

set CRSEPARATOR=yes (default=no)

[t00fri]

Hi Fridger,

Sorry I really don't know that there is a difference between DOS and UNIX text files. Yesterday I compared with an hex editor two files an could see the different line endings. Do you know an windows editor that can save files in UNIX format?

Bye Jens

Being rather an "amateur" in Windows issues, I noticed that Word 2002 allows to set the line endings for file saving in great detail.

Bye Fridger

[t00fri]

Oh, that's interesting. Which shells are you refering to that can digest scripts or commands with \CR's thrown in at
arbitrary places with line endings being sometimes \LF and sometimes \CR\LF??

What's the problem in treating them, when not quoted, just as

separators, like spaces, tabs, linefeeds...? This could be a customizable option, for example:

set CRSEPARATOR=yes (default=no)

Javier,

you did not answer which shell you were referring to above that "naturally" support mixed Windows-Unix line endings!?

Bye Fridger

[jamarsa]

Sorry, doing a little research on that matter. Going off-topic:

I'm not saying 'naturally' supported, only 'resigned' support of it . One of the hypothetical ways to do it should be the IFS (internal field separator) which defines the whitespaces used for expansion & whitespaces between arguments. Little test follows:

Code: Select all

bash-2.05b$ export IFS=" ^I^J^M"
bash-2.05b$ cat test.sh
#!/bin/zsh
ls -l $*
bash-2.05b$ set | grep IFS
IFS=$' \t\n\r'
bash-2.05b$ test.sh file1 file2^M
: No such file or directory
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file1
bash-2.05b$ . test.sh file1 file2^M
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file1
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file2
bash-2.05b$ . test.sh file1^Mfile2^M
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file1
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file2
bash-2.05b$ ls -l file1 file2^M
: No such file or directory
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file1
bash-2.05b$ export IFS=" ^I^J"
bash-2.05b$ . test.sh file1 file2^M
: No such file or directory
-rw-r--r--   1 javier   javier   6 sep 19 00:19 file1


As you see, sometimes the ^M is treated as a whitespace, if defined in IFS - but not always. In particular, the first call to test.sh shows that zsh doesn't import the IFS value, and the call to ls shows that bash doesn't treat ^M as whitespace when giving arguments to another command. But it does when uses itself the arguments.

According to this thread on the matter of treating CR, someone says:

POSIX disagrees with you (accd to the manual page)

$ man isspace
....
isspace()
checks for white-space characters. In the "C" and
"POSIX" locales, these are: space, form-feed
('\f'), newline ('\n'), carriage return ('\r'),
horizontal tab ('\t'), and vertical tab ('\v').

So, according to POSIX rules, ^M could be treated as a ' whitespace', just like 0x20.

This comment says that a ^M at end of line may be ignored by some Unix shells:

Many Unix systems will consider a `\r' in a DOS-type line-ending (`\r\n') part of the interpreter arguments. (HP-UX, Solaris, UnixWare ignore trailing `\r'. AIX, BSD/OS, FreeBSD, Linux, OpenBSD, Tru64 do not.)

Note: all these links refer to the #! line, and discuss the behaviour of the ^M in that line. I haven't still found any discussion of ^M in the rest of the script. So, I cannot answer 'which shell' right now, but there are candidates...

[t00fri]

Hi Javier,

I think in your thorough ^M research;-) you have clearly illustrated plenty of traps for ^M-ignorers like Jens;-), and nicely demonstrated how involved these matters really are and that a small "partial success" e.g. with some bash commands, does not mean much...

I agree completely with what you wrote.

Bye Fridger

[jamarsa]

My point is that Unix success is due to its flexibility. If you forbid the use of an 'approved' whitespace, you lose flexibility. BTW, why don't forbid tab also, and leave space only as separator?

The IFS somewhat 'erratic' behaviour is not Windows fault; it's bash/zsh fault. If you have an option to extend the field separators, let it work across all the language, don't limit it to certain uses.

From the bash homepage:

Bash is the shell, or command language interpreter, that will appear in the GNU operating system. Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification

If you intend to comply with the POSIX standards, comply with all of them, and give a mechanism to use all the defined whitespaces (and, if you want to enhance flexibility, other characters, such as commas, dots, semicolons, etc. as well, if you please! Just be sure to include compatibility mechanisms in your scripts, i.e. IFS=... ).

Again, why forbid ^M? Maybe because it is a 'DOSish' thing?