• (disco)

    paging @remy:

    [image]
  • (disco) in reply to accalia

    Foo, beat me to it by mere seconds.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Foo, beat me to it by mere seconds.

    :bow:

    and for once we have an article without a "Frist" comment!

    ..... DAMMIT!

  • (disco)

    This looks like something you would have to do if you couldn't persist a variable/object past each executable line... Oh wait.

  • (disco)

    .csv echo "AccountExpirationDate*accountExpires*AccountLockoutTime*AccountNotDelegated*...

    It looks like this is an asterisk-separated file. Shouldn't that make the extension .asv?

    Second, is there actually any script which can import restore this junk to Active Directory?

  • (disco) in reply to JBert

    csv is pretty universally accepted to be "delimiter-separated" nowadays instead of merely "comma-separated"

    An official standard for the CSV file format does not exist, but RFC 4180 provides a de facto standard for many aspects of it. In popular usage, however, the term CSV may denote some closely related delimiter-separated formats, which use a variety of different field delimiters. These include tab-separated values and space-separated values, both of which are popular. Such files are often even given a .csv extension, despite the use of a different field separator than the comma.

    Wikipedia

  • (disco) in reply to JBert
    JBert:
    Second, is there actually any script which can import this junk?

    Excel should be able to...if not, worst case is

    1. Ctrl+H
    2. Find: \*
    3. Replace: , (or whatever)
    4. Replace all
    5. Done.
  • (disco) in reply to rc4
    rc4:
    > An official standard for the CSV file format does not exist, ...

    Wikipedia

    > This article needs additional citations for verification

    Wikipedia

    rc4:
    JBert:
    Second, is there actually any script which can import this junk?

    Excel should be able to...if not, worst case is

    What I meant is that if this is a backup script, do they actually have a restore script as well? Having your account data in Excel will do you much good...

    I have edited my original post.

  • (disco) in reply to JBert
    JBert:
    This article needs additional citations for verification

    Okay? Somehow that makes everything in the article completely and totally untrue? Or are you just being obstinate?

    JBert:
    Having your account data in Excel will do you much good

    It will? No problem then, right?

  • (disco) in reply to JBert

    Since you're incorrigible, here's a little evidence (sadly, not many doctoral theses have been done on whether people type the star or the comma or the bar in between values on their computers) that may convince you that maybe that crazy thing is true because it's so hard to believe anyways:

    https://technet.microsoft.com/en-us/library/hh849932.aspx

    Microsoft's PowerShell has an Export-Csv cmdlet which both allows you to set the delimiter manually or set it based on the system's culture, because NOT EVERY COUNTRY IS THE SAME.

    It gets the current culture's TextInfo.ListSeparator property, which isn't the same in every country around the world! (.NET does this, too)

    Another piece is that when importing text data into excel, it allows you to select a delimiter, and several are offered (pipe, comma, semicolon, and colon, among others) by default, although you can specify your own.

  • (disco) in reply to JBert

    No backup procedure is ok until a restoration has been performed: in the meantime, it is just a waste of I/O.

  • (disco) in reply to JBert

    Actually it's asterix separated storage so the extension should be .ass

    :-P

  • (disco)

    Sometimes you really wonder whether the creators perpetrators of these sorts of scripts ever think “maybe there's a better way to do this”. :facepalm:

  • (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    No backup procedure is ok until a restoration has been performed: in the meantime, it is just a waste of I/O.

    My point exactly.

  • (disco) in reply to rc4
    rc4:
    Microsoft's PowerShell has an Export-Csv cmdlet which both allows you to set the delimiter manually or set it based on the system's culture, because NOT EVERY COUNTRY IS THE SAME.

    It gets the current culture's TextInfo.ListSeparator property, which isn't the same in every country around the world! (.NET does this, too)

    That's TRWTF. Why you would want to have your data format depend on the country of origin is beyond me.

  • (disco) in reply to Spectre
    Spectre:

    That's TRWTF. Why you would want to have your data format depend on the country of origin is beyond me.

    We'll get right on that, right after the US switches to SI units.

  • (disco)

    I've had this problem before. I'm sure there is some standard command line export or serialisation that can be used.

    CSV doesn't have an official standards but for most simple purposes people will:

    • Have a top row for comments.
    • Use , to separate and ,, (etc) for empty fields.
    • May remove trailing empty fields if it's a real issue but by default you don't.
    • Enquote strings containing the delimiter, use "" or " and \ to escape quotes. Delimiter can also be direct escaped.

    I've seen CSVs with separators, weird delimiters and padding because for some reason people think they have to be human readable when they don't. You use a converter for that or import into a spreadsheet.

  • (disco)

    As someone who does BASH/Unix and PowerShell scripting regularly this looks to me like a Unix guy trying to program PowerShell without learning how it works first. The problem here is not PowerShell, the problem is whoever wrote that mess. This can be done in 4 lines:

    Import-Module ActiveDirectory
$Date1 = Get-Date -uformat "%m-%d-%Y"
$LogFile = "D:\Reports\UserInfoDetailed.$Date1.csv"
Get-ADUser -Filter * |`
           Select AccountExpirationDate, accountExpires, AccountLockoutTime, AccountNotDelegated,`
                  AllowReversiblePasswordEncryption, BadLogonCount, badPasswordTime, badPwdCount,`
                  C, CannotChangePassword, CanonicalName, City, CN, codePage, Comment, Company,`
                  Country, countryCode, Created, createTimeStamp, Deleted, Department, Description,`
                  DisplayName, DistinguishedName, Division, DoesNotRequirePreAuth, dSCorePropagationData,`
                  EmailAddress, EmployeeID, EmployeeNumber, employeeType, Enabled, Fax, GivenName,`
                  HomeDirectory, HomedirRequired, HomeDrive, HomePage, HomePhone, Initials, instanceType,`
                  isCriticalSystemObject, isDeleted, LastBadPasswordAttempt, LastKnownParent, LastLogonDate,`
                  LockedOut, lockoutTime, LogonWorkstations, Manager, MemberOf, MNSLogonAccount, MobilePhone,`
                  Modified, modifyTimeStamp, Name, nTSecurityDescriptor, ObjectCategory, ObjectClass, ObjectGUID,
                  objectSid, Office, OfficePhone, Organization, OtherName, PasswordExpired, PasswordLastSet,`
                  PasswordNeverExpires, PasswordNotRequired, POBox, PostalCode, PrimaryGroup, primaryGroupID,`
                  ProfilePath, ProtectedFromAccidentalDeletion, pwdLastSet, SamAccountName, sAMAccountType,`
                  ScriptPath, sDRightsEffective, ServicePrincipalNames, SID, SIDHistory, SmartcardLogonRequired,`
                  State, StreetAddress, Surname, Title, TrustedForDelegation, TrustedToAuthForDelegation,`
                  UseDESKeyOnly, userAccountControl, UserPrincipalName, uSNChanged, uSNCreated, whenChanged,`
                  whenCreated | ConvertTo-Csv -Delimiter "*" | Out-File -FilePath $LogFile -Encoding utf8
  • (disco) in reply to isthisunique

    Actually the worst is that people use , blindly as a separator.

    I usually prefer ; as it is rare that that could show up in data other than text.

    Especially since some country-settings specify to use , as the decimal point (we do in Denmark) causing all manner of fun when some rows contain floating point values (other places it is used as a 1000 - separator which also can result in hilarity).....

  • (disco) in reply to Yazeran

    Yazeran the worst is when people keep changing delimiters to avoid collisions instead of using an escape sequence.

  • (disco) in reply to Yazeran
    Yazeran:
    Actually the worst is that people use , blindly as a separator.

    I usually prefer ; as it is rare that that could show up in data other than text.

    Especially since some country-settings specify to use , as the decimal point (we do in Denmark) causing all manner of fun when some rows contain floating point values (other places it is used as a 1000 - separator which also can result in hilarity).....

    In general, however, it is worse than that. It isn't a "1000-separator" in India, because the groups aren't all the same size... (But of course that doesn't affect the justification for not using commas.)
  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    "1000-separator"

    the kraw and the lac....or however you spell them....

    -shudder-

    i18n is hard guyz!

  • (disco) in reply to Yazeran
    Yazeran:
    I usually prefer ; as it is rare that that could show up in data other than text.

    If you've got control over what is being generated, tabs are a really good choice. They virtually never turn up in structured data or user input. It's only once you get into source code and full documents that they start to make a natural appearance.

    The evil option is to use a NUL. :smiling_imp:

  • (disco) in reply to dkf
    dkf:
    The evil option is to use a NUL. :smiling_imp:

    Or \b

  • (disco) in reply to dkf
    dkf:
    The evil option is to use a NUL. :smiling_imp:

    Doesn't the Windows API use null-delimited lists in some places?

  • (disco) in reply to LB_
    LB_:
    Doesn't the Windows API use null-delimited lists in some places?

    I don't know, but it wouldn't surprise me. The POSIX API certainly does (and tries to hide the fact from you).

  • (disco)
    PaulaBean:
    -uformat "%m-%d-%Y"

    TRWTF is failure to use ISO8601 dates, amirite?

  • (disco) in reply to dkf
    dkf:
    If you've got control over what is being generated, tabs are a really good choice. They virtually never turn up in structured data or user input.

    That's what we do - our WTF is what we use for empty fields, cause somebody vetoed trailing tabs.

  • (disco) in reply to LB_
    LB_:
    Doesn't the Windows API use null-delimited lists in some places?

    Two places I know of:

    • GetEnvironmentStrings() returns a list of null-terminated strings, terminated by an empty string (== two null characters).
    • The lpstrFilter member of the OPENFILENAME structure (used GetOpenFileName() and GetSaveFileName() for displaying file chooser dialogs) is a list of null-terminated strings, again terminated by an empty string (== two null characters)
  • (disco) in reply to jkshapiro
    jkshapiro:
    PaulaBean:
    -uformat "%m-%d-%Y"

    TRWTF is failure to use ISO8601 dates, amirite?

    ISO8601 is the one true date format.

    RFC2550 is tollerated as an alternate date format.

    ALL OTHERS ARE HERITICS AND MUST DIE!*

    (* The date formats i mean. the people who use them are salvageable with mild to moderate reeducation and do not need to be killed)

  • (disco) in reply to Chesspiece_Face
    Chesspiece_Face:
    This can be done in 4 lines:

    wall of code

    That's a pretty generous definition of "line" you have there...

  • (disco) in reply to dkf
    dkf:
    The evil option is to use a NUL. :smiling_imp:

    Ooohhh I have to remember that one Evil cackling laughter

    On the issue of tabs as separator, then yes they work, but there is one caveat, and that is if some bozo edits your scv file and somehow deletes one of the tabs and then replaces it with the requisite number of spaces for the 'data to line up as it should'...

  • (disco) in reply to Yazeran
    Yazeran:
    scv file
    [image]

    Orders Received!

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Foo

    https://wiki.guildwars2.com/images/6/66/Quaggan.jpg

  • (disco) in reply to isthisunique
    isthisunique:
    CSVs with separators, weird delimiters

    I once dealt with CSV files where the delimiter was the string SPLIT_CHAR. At least in never needed to be escaped in data.

    isthisunique:
    human readable
    That definitely did not help make the CSV human readable.
  • (disco) in reply to HardwareGeek
    HardwareGeek:
    SPLIT_CHAR

    E_NOT_CHARACTER

  • (disco) in reply to Chesspiece_Face
    [image]

    4 lines, huh?

    LB_:
    Doesn't the Windows API use null-delimited lists in some places?

    What is the format of a double-null-terminated string with no strings? [Old New Thing]

    Spoiler: [spoiler]'\0'[/spoiler]

  • (disco) in reply to ben_lubar
    ben_lubar:
    HardwareGeek:
    SPLIT_CHAR

    E_NOT_CHARACTER

    Agreed. I didn't do it, and it was a bit beyond the scope of my project to clean up the mess (which would have eliminated the CSV files entirely — 1. Parse data from files. 2. Write data to CSV file. 3. Discard parsed data. 4. Read and parse CSV file. 5. Use data. — steps 2, 3, and 4 entirely superfluous, and originally 2 was very, very slow).

  • (disco) in reply to HardwareGeek

    Wait, did you need random access on a CSV file for some reason? Why not just do the transformation while you read the file instead of writing it out and reading it back in?Whoops, misread that explanation.

  • (disco) in reply to Spectre
    Spectre:
    rc4:
    Microsoft's PowerShell has an Export-Csv cmdlet which both allows you to set the delimiter manually or set it based on the system's culture, because NOT EVERY COUNTRY IS THE SAME.

    It gets the current culture's TextInfo.ListSeparator property, which isn't the same in every country around the world! (.NET does this, too)

    That's TRWTF. Why you would want to have your data format depend on the country of origin is beyond me.

    Did someone say "country"?

    United States, Canada, Mexico, Panama, Haiti, Jamaica, Peru, Republic Dominican, Cuba, Carribbean, Greenland, El Salvador, too. Puerto Rico, Colombia, Venezuela, Honduras, Guyana, and still, Guatemala, Bolivia, then Argentina, And Ecuador, Chile, Brazil. Costa Rica, Belize, Nicaragua, Bermuda, Bahamas, Tobago, San Juan, Paraguay, Uruguay, Suriname, And French Guiana, Barbados, and Guam. Music* Norway, and Sweden, and Iceland, and Finland, And Germany, now in one piece, Switzerland, Austria, Czechoslovakia, Italy, Turkey, and Greece. Poland, Romania, Scotland, Albania, Ireland, Russia, Oman, Bulgaria, Saudi Arabia, Hungary, Cyprus, Iraq, and Iran. There's Syria, Lebanon, Israel, Jordan, Both Yemens, Kuwait, and Bahrain, The Netherlands, Luxembourg, Belgium, and Portugal, France, England, Denmark, and Spain. Music* music

    India, Pakistan, Burma, Afghanistan, Thailand, Nepal, and Bhutan, Kampuchea, Malaysia, then Bangladesh (Asia), And China, Korea, Japan. Mongolia, Laos, and Tibet, Indonesia, The Philippine Islands, Taiwan, Sri Lanka, New Guinea, Sumatra, New Zealand, Then Borneo, and Vietnam. Tunisia, Morocco, Uganda, Angola, Zimbabwe, Djibouti, Botswana, Mozambique, Zambia, Swaziland, Gambia, Guinea, Algeria, Ghana. Even More Music

    Burundi, Lesotho, then Malawi, Togo, The Spanish Sahara is gone, Niger, Nigeria, Chad, and Liberia, Egypt, Benin, and Gabon. Tanzania, Somalia, Kenya, and Mali, Sierra Leone, and Algiers, Dahomey, Namibia, Senegal, Libya, Cameroon, Congo, Zaire. Ethiopia, Guinea-Bissau, Madagascar, Rwanda, Mayore, and Cayman, Hong Kong, Abu Dhabi, Qatar, Yugoslavia... Crete, Mauritania, then Transylviania, Monaco, Liechtenstein, Malta, and Palestine, Fiji, Australia, Sudan!

  • (disco) in reply to Yazeran
    Yazeran:
    Especially since some country-settings specify to use , as the decimal point (we do in Denmark) causing all manner of fun when some rows contain floating point values (other places it is used as a 1000 - separator which also can result in hilarity).....
    Apple Numbers has a similar problem: import a comma-separated file when your locale’s decimals separator is a comma, and you get one cel for each line instead of each line being split into multiple cells. The only recourse I’ve found is to quit Numbers, change the decimals separator in the system preferences, open Numbers again, import the file, close Numbers, return the decimals separator to the correct symbol, re-open Numbers once more, and continue working on the file.
  • (disco) in reply to Protoman

    There's also the multi-string registry entry.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    SPLIT_CHAR

    How about ASCII 0x1E (record separator) or 0x1F (unit separator)? Everyone loves unprintable control characters in their text files, right?

    Gurth:
    Apple Numbers has a similar problem:

    I've never used Apple Numbers, but I suspect if you tried launching it from the console after setting the environment variable LC_ALL to something like en_US.utf-8, it would probably work (and just LC_NUMERIC may also be sufficient, too). That would save you the trouble of having to change a global system setting, but you'd still have to re-launch Numbers twice.

  • (disco) in reply to Spectre

    Because different countries have different "standards"? Are you an idiot, or were you born with a partially-developed brain? TRWTF is why not every country speaks English and uses the Metric system and the US Dollar. :trolleybus:

  • (disco) in reply to rc4
    rc4:
    were you born with a partially-developed brain?

    I'm pretty sure this is a "yes," as the human brain is typically not fully developed until around age 20.

  • (disco) in reply to Spectre

    Well, I manually wrapped the line for space reasons. It's long because of the select statement. Really, if you wanted to be able to read it back into an object later you'd use Export-Csv rather than ConvertTo-Csv, and you'd skip the select, the original codetastrophy above is saving EVERY attribute, even those that aren't defined, which is actually unnecessary except that the same coder probably had an equally awful solution for reading that mess back in.

    Example of a shorter 4-line solution:

    Import-Module ActiveDirectory
$Date1 = Get-Date -uformat "%m-%d-%Y"
$LogFile = "D:\Reports\UserInfoDetailed.$Date1.csv"
Get-ADUser -Filter * | Export-Csv -Delimiter "*" -Encoding utf8 -Path $LogFile
  • (disco) in reply to PJH

    See my reply to Spectre

  • (disco) in reply to chubertdev

    +,

  • (disco) in reply to HardwareGeek

    Here's your :pendant:.

  • (disco) in reply to Spectre
    Spectre:
    Chesspiece_Face:
    This can be done in 4 lines:

    wall of code

    That's a pretty generous definition of "line" you have there...

    What the heck, ONE(*) line, with no guarantee that this is even a wise way to try to backup your AD accounts.

    Get-ADUser -Filter * | Export-Csv -Delimiter "*" -Encoding utf8 -Path (Get-Date -UFormat "D:\Reports\UserInfoDetailed.%m-%d-%Y.csv")

    *) Assumes you have the AD module loaded, if not you'll need another line to load it.

Leave a comment on “Good Idea, Bad Idea”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article